Redémarrage sans modèle de contrôle reste coûteux

03.07.2026

6 min de lecture

De nombreux programmes de digitalisation tournent sans responsabilité claire pour le Capex et l’Opex. Le Capex couvre les investissements ponctuels, l’Opex les coûts d’exploitation et de licences. Les DSI et CDO de la région DACH ont besoin d’un modèle de pilotage solide avant d’autoriser de nouveaux programmes.

Les points clés en bref

Une responsabilité globale avant chaque euro dépensé. Sans responsable désigné, les commandes suivantes continuent ; dans le cas de la Smart-eID, plus de 90 millions d’euros ont été engagés malgré un risque d’échec quasi certain.
Séparer Capex et Opex. L’autorisation des investissements, la prise en charge de l’exploitation et le contrôle continu de la rentabilité permettent de suivre les bénéfices, les niveaux de service et les risques résiduels dans des comptes et des rôles distincts.
Un rôle unique de responsabilité. Le DSI est responsable de l’architecture et de l’exploitation, le CDO du portefeuille et des bénéfices, et le métier de la justification des bénéfices ; une responsabilité partagée des résultats génère des comités.
Valider et clôturer les étapes. Quatre étapes clés avec des critères d’arrêt stricts permettent de stopper l’automatisme de prolongement ; le conseil de surveillance pilote via l’engagement Capex, la charge Opex, les risques élevés et la justification des bénéfices.

Articles associésL’AI Act Omnibus reporte le statut « high risk » : la gouvernance reste / Quelle gouvernance après le déploiement des agents ?

Pourquoi les programmes sans responsable échouent

Un programme de digitalisation sans responsable global désigné reste une simple collection d’initiatives. Le budget, les délais et les promesses de valeur se répartissent entre plusieurs lignes. Personne n’est tenu de garantir le succès global. Lorsque le métier revendique la valeur, l’IT fournit la plateforme et le CDO en fait la promotion, il manque une entité pour trancher les conflits d’objectifs et décider des abandons.

La Cour des comptes fédérale décrit ce schéma dans son rapport consultatif de juillet 2025 sur la digitalisation de l’administration, adressé à la commission des finances du Bundestag. Selon elle, le gouvernement fédéral a exercé un pilotage insuffisant. Les stratégies numériques se sont limitées à des états des lieux sans analyse solide des lacunes. Les objectifs étaient souvent non mesurables. Les développements parallèles ont généré du « laisser-faire ». Des fonds ont été alloués sans que la rentabilité ne soit démontrée, les risques ignorés ou les ressources humaines manquantes. Le rapport cite en exemple le projet Smart-eID : dès 2021, le ministère de l’Intérieur avait classé le risque d’échec comme « quasi certain ». Pourtant, plus de 90 millions d’euros ont été engagés. Le projet a échoué. Pour les solutions EfA (Une solution pour tous), l’État a attribué aux Länder environ 500 millions d’euros sans vérifier au préalable la rentabilité des solutions envisagées. De nombreuses solutions sont restées limitées à un seul Land ou une seule commune, voire n’ont pas été utilisées du tout.

Dans les entreprises cotées en Bourse, cette lacune se manifeste souvent sous la forme d’un portefeuille sans priorisation contraignante. Le programme reste visible, mais la responsabilité des résultats reste négociable.

L’échec commence rarement par la technologie. Il survient lorsque personne ne souhaite assumer la responsabilité de l’abandon d’un projet non productif, faute de propriétaire formel. Les commandes suivantes, les prolongations de licences et les travaux d’intégration se poursuivent alors que la valeur métier n’est plus démontrée. Le modèle de pilotage IT doit donc imposer une responsabilité globale avant l’autorisation budgétaire et ne pas la rattraper a posteriori.

Séparer les dépenses d’investissement, les coûts d’exploitation et les risques opérationnels

Les équipes traitent souvent l’approbation des dépenses d’investissement (Capex) comme une décision d’investissement ponctuelle. Après le lancement, le statut du projet disparaît, tandis que les coûts d’exploitation (Opex), les licences et les risques opérationnels augmentent. Sans comptes séparés ni responsabilités distinctes, l’exploitation continue devient le poste résiduel de la décision d’investissement.

Un modèle robuste sépare trois niveaux décisionnels. Premièrement, l’approbation de l’investissement avec le business case, l’adéquation de l’architecture et l’hypothèse de valeur. Deuxièmement, la prise en charge opérationnelle avec les niveaux de service, la capacité et les exigences de sécurité. Troisièmement, le contrôle continu de la rentabilité, qui compare la croissance des Opex et les positions de risque à la valeur initialement promise. Le cadre de gouvernance COBIT 2019 d’ISACA formalise précisément cette séparation : EDM02 pilote la justification de la valeur (Benefits Delivery), APO05 la gestion et la priorisation du portefeuille, et la domaine DSS l’exploitation continue. ITIL 4 complète ce dispositif avec la gestion des niveaux de service et l’accompagnement des changements. Là, les équipes évaluent les risques avant l’approbation et pilotent les modifications en cours de service.

Le risque opérationnel doit figurer dans la logique d’approbation. Qui valide de nouveaux canaux, flux de données ou composants d’IA assume les risques de panne, de conformité et de dépendance en exploitation. Si les Capex et les Opex sont confondus dans une même ligne, le risque reste invisible jusqu’à ce qu’il se matérialise dans un incident ou un audit. La séparation apporte de la clarté : qui investit, qui exploite et qui porte le risque résiduel.

Matrice des rôles pour le DSI, le CDO et les métiers

Un modèle de pilotage repose sur une matrice des rôles qui définit les droits décisionnels et les voies d’escalade. Le DSI est responsable de l’intégrité de l’architecture, de la capacité opérationnelle ainsi que des normes de sécurité et d’approvisionnement. Le CDO pilote les priorités du portefeuille, la logique de valeur et le lien avec les modèles économiques. Les métiers détiennent l’exigence fonctionnelle, la justification de la valeur et le travail de transformation des processus.

La matrice doit anticiper les conflits. Qui tranche en cas de roadmaps concurrentes ? Qui stoppe un projet si la valeur escomptée n’apparaît pas ? Qui assume les coûts si le périmètre s’élargit et que la plateforme doit rester stable ? Sans cette clarification, on assiste à un pilotage parallèle : programmes du CDO à côté de projets IT, outils métiers à côté de l’architecture d’entreprise. COBIT 2019 propose des matrices RACI (Responsible, Accountable, Consulted, Informed) pour chaque objectif de gouvernance et de management, ainsi que pour les structures décisionnelles organisationnelles. ISACA précise : les matrices RACI ne remplacent pas la responsabilité. Elles la clarifient. Plusieurs rôles « Accountable » pour un même résultat forment un comité. La responsabilité du propriétaire n’émerge qu’avec un seul rôle « Accountable ».

Les doubles rôles sont possibles. La responsabilité partagée pour un même résultat ne l’est pas. Si le DSI et le CDO sont une seule et même personne, la séparation entre responsabilité de la plateforme et pilotage du portefeuille doit nonetheless être documentée. Les métiers peuvent formuler des exigences, mais pas créer une informatique fantôme comme état permanent. La matrice n’a d’effet que si elle est couplée aux droits budgétaires et d’approbation.

Logique des portes (Gates) pour les approbations et les arrêts

La gouvernance des programmes de digitalisation nécessite des portes (Gates) qui autorisent ou interrompent. Quatre portes sont un minimum dans la pratique : approbation du concept et de l’architecture, approbation de l’investissement, prise en charge opérationnelle, ainsi qu’un contrôle périodique de la valeur et des risques. Chaque porte doit comporter des critères d’arrêt stricts, et pas seulement des feux tricolores.

Les critères d’arrêt doivent être définis avant le premier euro dépensé. Parmi les exemples : absence de justification de la valeur, absence de prise en charge opérationnelle, lacunes de sécurité sans plan de remédiation ou rupture architecturale par rapport à la cible. Qui ne traite les arrêts que de manière politique protège les dépenses en cours et pénalise les décisions d’arrêt honnêtes. Le modèle Stage-Gate de Robert G. Cooper formalise cette logique depuis des décennies : à chaque porte, des gardiens vérifient les critères prédéfinis et décident entre Go, Kill, Hold ou Recycle. Les portes sont des décisions d’investissement avec engagement de ressources. Les réunions de suivi reflètent l’avancement, les portes engagent ou libèrent les fonds. Le Bundesrechnungshof recommande, dans son rapport 2025, la même approche structurelle pour les fonds publics numériques : approbation uniquement si le projet contribue aux objectifs numériques politiques, est économique, respecte les normes et prend en compte les risques.

La logique des portes doit s’inscrire dans le portefeuille, et non dans la méthodologie de projet individuel. Un projet peut être méthodologiquement irréprochable tout en étant stratégiquement superflu. C’est pourquoi l’instance de pilotage doit avoir la compétence d’arrêter un projet malgré des succès partiels, si l’engagement Capex, le chemin Opex ou le risque opérationnel dépassent la valeur créée. Une approbation sans option d’arrêt devient une mécanique de reconduction automatique.

Ce que le conseil de surveillance doit vraiment voir

Le conseil de surveillance n’a pas besoin de listes de fonctionnalités ni de redémarrages PowerPoint. Il a besoin d’une vision concise sur l’engagement du Capex, l’évolution des Opex, les risques opérationnels critiques et l’état des preuves de valeur par programme. Cela inclut la responsabilité, la prochaine décision de porte, ainsi que des options explicites d’abandon ou de recentrage.

Seul ce qui permet de prendre des décisions est digne d’être rapporté. Un feu tricolore sans proposition décisionnelle exonère la direction et bloque le conseil de surveillance. Il est judicieux de se limiter à quelques indicateurs clés, dont l’interprétation est claire : Capex investi et encore engagé, charge Opex en cours par programme, risques majeurs non résolus et part des projets dont la valeur a été confirmée. Le Code allemand de gouvernement d’entreprise (DCGK) fixe le cadre : le principe 4 exige un système interne de contrôle et de gestion des risques adapté et efficace. La recommandation A.5 impose dans le rapport de gestion de présenter les principales caractéristiques de ces systèmes ainsi qu’une déclaration sur leur adéquation et leur efficacité. Le principe 6 associe le conseil de surveillance aux décisions d’importance fondamentale et exige des réserves d’approbation. Les risques liés à l’IT et au numérique entrent dans ce mandat de surveillance dès qu’ils affectent matériellement l’activité de l’entreprise.

Les récits politiques sur les programmes ne remplacent pas la gouvernance d’entreprise. Les initiatives publiques de digitalisation peuvent servir de repères, mais elles ne dispensent ni de la discipline Capex ni de la responsabilité opérationnelle au sein de l’entreprise. Le conseil de surveillance devrait s’enquérir du modèle de pilotage, et non du marketing du prochain redémarrage. La transparence s’installe lorsque les décisions d’arrêt sont aussi reportables que les autorisations.

Autoriser de nouveaux programmes digitaux sans avoir défini la responsabilité, la séparation Capex-Opex, la matrice des rôles et la logique des portes revient à financer la perpétuation plutôt que le pilotage. Le modèle de pilotage IT est la condition préalable au prochain redémarrage – bien avant le prochain dépassement de budget.

Foire aux questions

Comment lier efficacement la matrice des rôles aux droits budgétaires et d’approbation ?

La matrice ne s’applique que si le rôle responsable décide également de l’allocation des fonds. Les approbations en capital (Capex) et les comptes d’exploitation (Opex) sont gérés par le propriétaire désigné ; les extensions de périmètre du service déclenchent de nouvelles évaluations aux portes (gates). Les budgets parallèles en dehors de la matrice génèrent une gestion parallèle et rendent caduque la logique RACI documentée.

Qu’est-ce qui distingue une vraie porte d’évaluation (Gate) d’une réunion de suivi ?

Les réunions de suivi reflètent l’avancement. Les portes d’évaluation (Gates) tranchent sur l’allocation des ressources et mettent fin ou maintiennent les projets selon des critères prédéfinis. Les décideurs (Gatekeepers) choisissent entre Go, Kill, Hold ou Recycle ; sans option d’arrêt, toute approbation devient une simple formalité de continuation. Cette logique doit s’intégrer au portefeuille, car des projets individuels, même menés avec rigueur méthodologique, peuvent s’avérer stratégiquement superflus.

Comment maîtriser les risques opérationnels après le lancement (Go-Live) ?

Après l’approbation de l’investissement, la prise en charge opérationnelle s’accompagne de niveaux de service, de capacités et d’exigences de sécurité. Ensuite, l’évaluation périodique de la rentabilité examine la croissance des Opex et les positions de risque par rapport aux bénéfices promis. De nouveaux canaux, flux de données ou composants d’IA introduisent des risques de panne, de conformité et de dépendance dans la logique d’approbation, tout en maintenant la charge visible sur des comptes séparés.

Quelle présentation décisionnelle faut-il soumettre au conseil de surveillance au lieu de simples tableaux de feux tricolores ?

Seule une information décisionnelle est pertinente. Il est judicieux de présenter le capital engagé et encore bloqué, la charge Opex en cours par programme, les risques élevés non résolus et la part des projets disposant d’une preuve de valeur confirmée. Chaque indicateur nécessite un propriétaire, une prochaine décision aux portes (Gate) ainsi que des options explicites d’arrêt ou de recalibrage. Ainsi, la mission de surveillance s’applique efficacement aux risques numériques matériels.