Le schéma directeur informatique a mauvaise réputation dans les PME. On l’associe aux grands groupes, à des mois d’ateliers et à un document épais que personne ne relit une fois validé. Cette image décrit une manière de le faire, pas l’outil lui-même. Ramené à l’essentiel, un schéma directeur répond à une question simple : quels investissements numériques l’entreprise va-t-elle faire sur les trois prochaines années, dans quel ordre, et pourquoi ?
Pour une PME, la réponse tient en quelques pages. Elle a surtout une qualité que n’ont pas les décisions prises au fil de l’eau : elle relie chaque dépense à un objectif de l’entreprise, et elle se relit chaque année pour tenir compte de ce qui a changé.
À quoi sert un schéma directeur informatique
Un schéma directeur du système d’information sert d’abord à arbitrer. Une PME reçoit chaque année plus de propositions d’investissement qu’elle ne peut en financer : un nouveau logiciel de gestion, une refonte du site, un renouvellement du parc, un projet d’intelligence artificielle. Sans cadre, elles sont retenues dans l’ordre où elles arrivent, ou selon l’insistance de celui qui les porte.
Il sert ensuite à séquencer. Certains projets dépendent d’autres : on ne connecte pas un outil de relation client à une gestion commerciale qu’on s’apprête à remplacer. Le schéma directeur rend ces dépendances visibles avant qu’elles coûtent un projet refait.
Il sert enfin à expliquer. Aux associés, à une banque, à un investisseur, à un repreneur : un plan écrit montre que les dépenses numériques obéissent à une logique, et qu’elles ont été pesées.
Ce qu’il n’est pas se dit aussi clairement. Ce n’est pas un catalogue d’outils à acheter, ni la feuille de route d’un éditeur rebaptisée plan d’entreprise, ni un exercice réservé au service informatique. Un schéma directeur rédigé par un prestataire qui vendra les projets qu’il annonce n’est pas un plan : c’est une proposition commerciale étalée sur trois ans.
Les étapes : état des lieux, cible, trajectoire, budget
Avant les étapes, une question de participants. Un schéma directeur de PME se construit avec la direction, qui fixe les objectifs et arbitre ; avec les responsables des métiers, qui savent ce que les outils actuels empêchent de faire ; et avec les prestataires, consultés pour ce qu’ils savent, pas pour ce qu’ils vendent. Écrit par le seul service informatique, il décrit ce que la technique souhaite ; écrit par la seule direction, il ignore ce qu’elle permet.
L’état des lieux
Ce qui existe : applications, équipements, prestataires, contrats, compétences internes, et ce qui ne fonctionne pas. Il se construit souvent à partir d’un audit informatique de PME, dont la liste de décisions priorisées fournit directement la matière des premières années.
La cible
Ce que le système d’information doit permettre dans trois ans, décrit à partir des objectifs de l’entreprise et non des outils : servir deux fois plus de clients sans recruter au même rythme, ouvrir un second site, vendre en ligne, sécuriser des données sensibles. La cible se formule en capacités, pas en logiciels.
La trajectoire
Le chemin entre les deux, découpé en projets, dans un ordre qui respecte leurs dépendances et la capacité de l’entreprise à absorber le changement. Plusieurs trajectoires sont souvent possibles ; les présenter côte à côte, avec leurs coûts et leurs risques, est la meilleure façon de faire décider la direction — c’est tout l’intérêt de construire le schéma directeur SI en trois scénarios chiffrés.
Le budget
Chaque projet de la trajectoire reçoit une estimation, en investissement et en coût récurrent — licences, maintenance, hébergement, temps interne. Le schéma directeur relie ainsi le plan au budget annuel : chaque année, la tranche correspondante entre dans le budget, et le plan est révisé à la lumière de ce qui a été réalisé.
C’est cette révision annuelle qui distingue un schéma directeur de PME d’un document de grand groupe. Une PME change vite : une acquisition, un nouveau marché, un départ clé. Un plan relu chaque année suit l’entreprise ; un plan figé la décrit telle qu’elle était.
Au terme de ces quatre étapes, le document tient en quelques pages :
| Partie | Contenu |
|---|---|
| Synthèse | Les objectifs, la trajectoire retenue et l’enveloppe globale, en une page lisible par un associé ou un banquier |
| État des lieux | Ce qui existe, ce qui fonctionne, ce qui bloque, et les risques identifiés |
| Cible | Les capacités attendues dans trois ans, reliées aux objectifs de l’entreprise |
| Trajectoire | Les projets, leur ordre, leurs dépendances et leurs responsables |
| Budget | Investissement et coût récurrent de chaque projet, réparti par année |
| Révision | La date de la prochaine relecture, et ce qui déclencherait une révision anticipée |
Du schéma directeur au cadrage de projet
Le schéma directeur dit quoi et quand. Il ne dit pas comment. Chaque projet qu’il annonce demande encore, au moment de le lancer, un cadrage propre : le besoin détaillé, les utilisateurs concernés, les contraintes, les critères de réception, le mode de choix du prestataire.
Le cadrage d’un projet informatique suit la même logique que celle d’un cahier des charges de site internet : décrire le problème avant la solution, rendre les réponses des prestataires comparables, fixer ce qui sera reçu. Le schéma directeur lui fournit son contexte — pourquoi ce projet, maintenant, et avec quel budget — ce qui lui épargne de réinventer à chaque fois les raisons de son existence.
Le premier projet mérite une attention particulière. Il doit être choisi pour ce qu’il débloque plutôt que pour ce qu’il montre : un projet discret qui rend les suivants possibles — remettre à plat les comptes et les accès, fiabiliser les sauvegardes, reprendre la main sur un contrat — vaut mieux qu’un projet visible qui repose sur des fondations fragiles.
L’articulation marche dans les deux sens. Un cadrage qui révèle un coût ou une difficulté imprévue doit remonter au schéma directeur, qui ajuste la trajectoire. Sans ce retour, le plan se détache progressivement de la réalité des projets.
AMOA : quand se faire accompagner côté client
L’assistance à maîtrise d’ouvrage, ou AMOA, désigne l’accompagnement du client — la maîtrise d’ouvrage, qui exprime le besoin et paie — face aux prestataires qui réalisent, la maîtrise d’œuvre. Son rôle est de défendre les intérêts du client : formuler le besoin, choisir les prestataires, suivre la réalisation, réceptionner le résultat.
Une PME a besoin de cet accompagnement dans trois cas : quand elle n’a personne en interne pour tenir ce rôle, quand un projet dépasse nettement la taille de ceux qu’elle a déjà conduits, et quand l’écart de compétence avec le prestataire est tel qu’elle ne peut pas juger ce qu’on lui livre. Dans une PME sans direction informatique, c’est souvent le DSI à temps partagé qui tient ce rôle sur la durée, et qui porte le schéma directeur d’une année sur l’autre.
La condition, là encore, est l’indépendance. Celui qui accompagne le client ne doit pas être rémunéré par le prestataire qu’il aide à choisir. C’est la position que tient Maeliom Consulting sur ces missions : du côté de celui qui décide et qui paie.
Questions fréquentes
Une PME a-t-elle vraiment besoin d’un schéma directeur informatique ?
Dès qu’elle doit arbitrer entre plusieurs investissements numériques sur plusieurs années, oui — sous une forme courte. Il évite de décider projet par projet, dans l’ordre d’arrivée des propositions.
Sur quelle durée porte un schéma directeur ?
Trois ans est un horizon courant pour une PME : assez long pour séquencer les projets, assez court pour rester crédible. Il se révise chaque année.
Quelle différence entre schéma directeur et cahier des charges ?
Le schéma directeur planifie l’ensemble des investissements numériques sur plusieurs années. Le cahier des charges décrit un projet précis au moment de le confier à un prestataire.