par Le schéma directeur informatique est l’un des documents les plus attendus dans une organisation, et l’un des plus vite oubliés. On le commande, on mobilise des consultants ou des équipes internes pendant plusieurs mois, on le valide en séance, puis il rejoint une étagère. Deux ans plus tard, on constate que les projets réellement menés ne correspondent qu’en partie à ce qui avait été écrit.
J’ai participé à l’élaboration et à la mise en œuvre des premiers schémas directeurs informatiques de deux commissions régionales, puis j’ai piloté l’élaboration d’un schéma directeur triennal pour une institution financière. D’un exercice à l’autre, j’ai observé la même ligne de partage entre les schémas qui transforment et ceux qui décorent : la présence ou l’absence d’arbitrage budgétaire.
1. Le symptôme : trente projets, tous prioritaires
Un schéma directeur sans arbitrage se reconnaît facilement. Il comporte une longue liste de projets, chacun décrit avec soin. Tous sont qualifiés de prioritaires ou de stratégiques. Le chiffrage est absent, ou global, ou renvoyé à « une étude ultérieure ». Le calendrier est indicatif. Les responsables sont des directions, pas des personnes.
Ce document a une qualité : il ne mécontente personne. Chaque direction y retrouve son besoin, ce qui facilite la validation. C’est précisément son défaut. Un document qui ne crée aucun désaccord n’a probablement rien décidé.
2. Ce qu’est réellement un schéma directeur
Un schéma directeur est un outil de décision. Il doit permettre à la direction générale de répondre à trois questions :
- Quels projets informatiques servent le plus directement la stratégie de l’organisation ?
- Dans quel ordre les réaliser, compte tenu des dépendances techniques et de la capacité de l’organisation à absorber le changement ?
- Avec quelles ressources, et donc au détriment de quoi ?
La troisième question est la plus inconfortable, et c’est celle qui donne sa valeur à l’exercice. Le budget informatique n’est jamais illimité. Les compétences internes non plus. Chaque projet retenu mobilise des personnes qui ne seront pas disponibles pour un autre.
3. Les quatre conditions d’un projet inscrit
Pour qu’un projet figure dans le schéma directeur comme un engagement, et non comme une intention, je considère qu’il doit remplir quatre conditions.
| Condition | Question à poser | Ce qui se passe si elle manque |
| Coût estimé | Combien coûte le projet, investissement et fonctionnement sur trois à cinq ans ? | Le projet est voté puis bloqué à la première revue budgétaire |
| Sponsor nommé | Quelle personne, côté métier, porte le projet et arbitre en cas de conflit ? | Le projet devient « un projet de l’informatique » et perd ses utilisateurs |
| Bénéfice mesurable | Quel indicateur doit évoluer, et de combien ? | Impossible de dire, à la fin, si le projet a réussi |
| Place dans le calendrier | À quel exercice budgétaire le projet est-il rattaché ? | Tous les projets démarrent en même temps et aucun n’avance |
Le coût de fonctionnement mérite une attention particulière. Beaucoup de schémas directeurs chiffrent l’investissement initial et oublient les licences annuelles, la maintenance, l’hébergement et les compétences nécessaires pour exploiter la solution. Or c’est souvent ce coût récurrent qui pèse le plus sur les budgets des années suivantes.
4. Comment arbitrer concrètement
L’arbitrage n’est pas une affaire d’intuition. Une méthode simple, que j’ai vu fonctionner, consiste à évaluer chaque projet selon quelques critères pondérés :
- contribution à la stratégie de l’organisation ;
- réduction des risques (sécurité, conformité, continuité d’activité) ;
- gains attendus (délais, coûts, qualité de service) ;
- coût total sur la durée du schéma ;
- complexité et risque de mise en œuvre.
Le résultat n’est pas une vérité mathématique, mais il oblige chaque porteur de projet à argumenter avec les mêmes règles que les autres. Il rend aussi visibles les projets de fond, comme la sécurité ou la continuité, qui ne sont réclamés par aucun métier mais protègent tous les autres.
Vient ensuite la confrontation avec l’enveloppe budgétaire prévisible. Les projets sont classés, et l’on trace une ligne : au-dessus, ce qui sera fait sur la période ; en dessous, ce qui attendra. Cette ligne doit être validée par la direction générale, pas par la seule direction informatique.
5. Un document vivant, pas un monument
Un schéma directeur de trois ans ne survit pas intact à trois exercices budgétaires. Les priorités changent, une réglementation nouvelle apparaît, un incident de sécurité impose une réorientation. Le bon réflexe n’est pas de réécrire le document, mais d’organiser une revue annuelle :
- bilan des projets engagés, avec les indicateurs prévus ;
- mise à jour des coûts et des calendriers ;
- nouvel arbitrage sur les projets en attente, à la lumière du budget de l’année suivante.
Cette revue annuelle est aussi le moment où le schéma directeur rejoint le cycle budgétaire. Sans ce lien, le schéma et le budget vivent dans deux mondes séparés, et c’est toujours le budget qui gagne.
6. Ce que j’ai appris
Le moment le plus difficile dans l’élaboration d’un schéma directeur n’est pas la rédaction. C’est la réunion où il faut écrire noir sur blanc qu’un projet attendu par une direction influente sera reporté, par exemple parce que la sécurisation de l’infrastructure doit passer avant. C’est aussi à partir de ce moment que le document commence réellement à servir : construire une application nouvelle sur une infrastructure fragile coûte toujours plus cher, à terme, que de différer cette application d’un an.
Conclusion
Un schéma directeur informatique ne vaut que par les choix qu’il assume. Sans arbitrage budgétaire, il reste un catalogue, utile pour recenser les besoins, inutile pour piloter. Avec des arbitrages explicites, validés au bon niveau et revus chaque année, il devient ce qu’il doit être : l’instrument par lequel la direction décide de ce que l’informatique fera pour l’organisation, et de ce qu’elle ne fera pas.
