Gouvernance du SI : qui décide quand tout devient prioritaire ?

GOUVERNANCE & ARBITRAGES

Les équipes informatiques travaillent beaucoup. Les métiers attendent. Le budget augmente. Et lorsqu’on demande ce qui va réellement sortir, la réponse devient moins claire.

Dans la première version de cet article, je décrivais déjà ce décalage entre l’activité de la DSI et ce que l’entreprise en comprend. Je parlais de gouvernance des technologies de l’information. Le terme reste juste. Mais il évoque souvent des comités, des processus et des présentations que personne n’a envie d’ajouter à son agenda.

Une gouvernance utile doit d’abord permettre de décider ce qui avance, ce qui attend et qui porte la décision. Si elle ne change aucun engagement, elle risque surtout de consommer du temps.

La gouvernance du SI concerne les décisions de l’entreprise

Un changement d’ERP, un nouvel outil commercial ou une automatisation ne mobilisent pas seulement l’informatique. Ils touchent aux règles métier, aux responsabilités, à la disponibilité des équipes et parfois aux engagements envers les clients.

La DSI peut éclairer les dépendances et proposer une trajectoire. Elle ne peut pas décider seule de toutes les conséquences pour l’entreprise. À l’inverse, une direction ne peut pas demander une date sans regarder les moyens et les arbitrages nécessaires.

C’est à cet endroit que la gouvernance devient concrète : relier une intention à un engagement que l’organisation peut tenir. La technologie fait partie du sujet. Elle n’en porte pas toutes les décisions.

Pourquoi les réunions ne débloquent-elles pas les projets ?

On peut connaître les retards et pourtant ne rien changer. Le problème est parfois déjà visible : trop de chantiers, des sponsors absents, des besoins qui se précisent au fil du travail et personne qui veut annoncer à un service que son projet attendra.

Tout finit alors par remonter au directeur général. Mais s’il découvre le dossier au moment de l’arbitrage, sans options claires ni conséquences compréhensibles, sa décision devient difficile. Le sujet repart pour une prochaine réunion. Entre-temps, rien ne s’arrête.

Ce mécanisme est au cœur de mon enquête sur la surcharge des projets et le renoncement. Ici, je m’intéresse au dispositif pratique qui peut éviter de reproduire cette situation.

Commencer par les engagements réellement en cours

Avant de choisir un logiciel de portefeuille ou de multiplier les indicateurs, il faut savoir ce qui occupe l’organisation. Les projets annoncés ne sont pas toujours les seuls consommateurs de capacité : support, incidents, obligations, petites demandes et travaux déjà promis comptent aussi.

Je commencerais avec un inventaire lisible. Pour chaque sujet : le résultat attendu, le responsable métier, les équipes sollicitées, la prochaine décision et les dépendances importantes.

Il ne s’agit pas de tout modéliser au jour près. Il s’agit de voir où les mêmes personnes sont engagées plusieurs fois, où un besoin attend un arbitrage et où une date repose sur une disponibilité imaginaire.

Un sponsor doit pouvoir décider, pas seulement soutenir

Nommer quelqu’un sur une fiche projet ne suffit pas. Le sponsor doit comprendre ce que le projet change, mobiliser les bons interlocuteurs et arbitrer ce que le métier accepte de simplifier, de différer ou d’abandonner.

De son côté, la personne qui pilote doit rendre visibles les choix possibles. « Nous sommes en retard » est une information. « Nous pouvons tenir cette échéance en réduisant ce périmètre, ou garder le périmètre en décalant cette autre demande » prépare une décision.

Le comité de direction doit surtout intervenir lorsque l’arbitrage dépasse un seul service : concurrence pour une même ressource, modification d’une priorité stratégique, risque partagé ou conflit entre objectifs.

Une réunion utile repart avec des engagements différents

Pour préparer l’échange, je recommande de formuler les décisions attendues à l’avance. Quelques lignes peuvent suffire : question, options, conséquences, recommandation et responsable de la décision.

La réunion ne doit pas devenir une lecture collective de tous les statuts. Elle doit traiter les points qui ne peuvent pas être résolus au niveau des équipes.

• Démarrer : avec un périmètre suffisamment clair et une capacité réellement disponible.
• Poursuivre : parce que le résultat reste utile et que les conditions tiennent.
• Corriger ou différer : en précisant ce qui change et ce qui devient possible.
• Arrêter : avec un responsable pour fermer le sujet et traiter ses conséquences.

Gardez une trace courte : décision, raison, responsable et date de réexamen. Une décision introuvable quelques semaines plus tard finit souvent par être rediscutée comme si elle n’avait jamais existé.

Avec le no-code et l’IA, la visibilité devient encore plus importante

Un outil peut être acheté ou un prototype fabriqué sans projet formel. Cela peut être très utile. Mais l’application utilise parfois des données partagées, crée une nouvelle dépendance ou devient indispensable à un service.

La réponse ne consiste pas à faire passer chaque essai devant le CODIR. Il faut adapter les règles à ce qui est en jeu : expérimentation limitée, usage partagé ou fonctionnement critique. Définissez quand un essai doit être déclaré, sécurisé et repris dans un cadre commun.

Le guide no-code, low-code et IA développe précisément ce passage entre une application qui fonctionne et un service que l’entreprise sait faire tenir.

Les référentiels peuvent aider. Ils ne prennent pas la décision

Les référentiels de gouvernance et de gestion des services restent des points d’appui possibles. Leur valeur dépend de ce que l’on en fait. Une PME n’a pas besoin d’adopter tous les mécanismes d’un grand groupe pour clarifier ses responsabilités.

Je préfère commencer par un dispositif proportionné, observer ce qu’il débloque et ajouter seulement ce qui manque. Si personne ne sait qui décide, un nouvel outil de suivi ne réglera pas cette absence.

La gouvernance commence à servir lorsque l’entreprise cesse de promettre davantage qu’elle ne peut réaliser.

Reprendre la main sur le portefeuille

Un diagnostic SI aide à comprendre les engagements et les risques. Un accompagnement CIO Office permet ensuite de préparer les arbitrages et d’aider le DSI à porter les sujets qui dépassent son équipe. Le budget IT doit être cohérent avec ces décisions.

Vos projets s’accumulent et les décisions n’aboutissent pas ? Parlons de votre situation.

Article initial conservé à la même adresse et refondu le 14 octobre 2026.

Retrouver les guides du Laboratoire de la décision →