Imagine une situation illustrative : un projet métier doit ouvrir rapidement un nouveau canal de vente. L’équipe a déjà choisi une solution SaaS, le fournisseur promet une intégration simple et le sponsor réclame une mise en service immédiate. L’analyse révèle pourtant une authentification séparée, des données dupliquées et aucune stratégie de sortie. Le comité d’architecture doit alors décider. Accepter préserve le calendrier, mais crée une dépendance durable ; refuser protège le système d’information, mais expose la DSI à l’accusation de bloquer l’activité. C’est précisément dans cet inconfort que le comité prouve son utilité.
L’exception devient la règle par accumulation
Une exception isolée paraît presque toujours défendable. Le problème apparaît lorsque dix décisions locales, chacune raisonnable dans son contexte, composent une architecture globalement ingérable. Une application conserve son annuaire, une autre impose son outil d’intégration, une troisième contourne le référentiel de données. Les coûts ne surgissent pas au moment de la décision : ils réapparaissent dans l’exploitation, les audits, les incidents, les renouvellements contractuels et les projets suivants.
Le mécanisme est aggravé lorsque l’achat précède l’instruction. Le comité ne reçoit plus une demande, mais un fait accompli : budget engagé, communication lancée, délai promis. Son choix devient artificiellement binaire entre avaliser l’écart ou provoquer un retard visible. Un DSI lucide traite donc le contournement comme un problème de gouvernance, pas seulement comme une faute technique.
Donner au comité un mandat qui permet de trancher
Un comité sans droits de décision produit des avis que chacun interprète. Son mandat doit préciser les standards relevant de son autorité, les cas exigeant une exception, les responsables habilités à accepter le risque et le niveau d’escalade en cas de désaccord. Il arbitre les écarts structurants ; il ne redessine pas chaque solution et ne remplace ni les architectes de domaine, ni les équipes produit, ni le RSSI.
Cette frontière est essentielle. Trop large, le comité devient un goulot d’étranglement. Trop étroite, il découvre les dépendances après signature. Le DSI peut fixer une règle simple : décision au niveau le plus proche du terrain tant que les standards sont respectés ; instruction formelle dès qu’un écart affecte la sécurité, les données, l’intégration, la réversibilité, la continuité ou les coûts partagés.
Instruire une exception comme une décision d’entreprise
La demande doit tenir dans un dossier court, mais complet : standard concerné, motif opérationnel, options examinées, bénéfice attendu, risques introduits, coût total, durée souhaitée, responsable et plan de sortie. L’absence d’une de ces informations n’appelle pas forcément un refus définitif ; elle justifie un retour pour complément, sans transformer le comité en atelier de conception.
L’examen suit ensuite une séquence stable. D’abord, vérifier si l’urgence est réelle ou résulte d’une décision tardive. Puis comparer l’exception à une solution conforme, même moins confortable. Ensuite, évaluer les conséquences sur la continuité, le risque cyber, la conformité, la souveraineté, les fournisseurs et la capacité d’évolution. Enfin, rendre une décision explicite : accord, accord conditionnel, refus ou escalade. Si le désaccord bloque le projet, un arbitrage de direction sous cinq jours évite que l’attente devienne une approbation tacite.
Dire non sans opposer architecture et métier
Un refus utile ne se résume jamais à « hors standard ». Il nomme le risque que l’entreprise ne doit pas subir, indique qui le porterait et propose une voie praticable. Le comité peut refuser le SaaS choisi tout en autorisant un pilote sans données sensibles, demander une intégration par le socle existant ou conditionner le lancement à une clause de réversibilité. Il protège ainsi la décision économique au lieu de défendre une préférence technologique.
Le compromis acceptable dépend aussi de la criticité. Une dérogation limitée, isolée et réversible peut accélérer une expérimentation. Le même écart devient inacceptable lorsqu’il touche un processus vital, multiplie les identités, enferme les données ou transfère une responsabilité sans propriétaire. Savoir dire non consiste donc moins à appliquer mécaniquement une norme qu’à reconnaître le moment où l’intérêt local menace la capacité collective.
Piloter les exceptions par des preuves
Le nombre brut d’exceptions ne suffit pas. Le DSI doit suivre le délai de décision, la part des dossiers incomplets, les motifs récurrents, les dérogations arrivées à échéance, les plans de retour au standard en retard et les incidents auxquels un écart a contribué. Il faut aussi distinguer les refus maintenus des refus renversés en escalade : une série de renversements signale soit un comité déconnecté des priorités, soit un mandat insuffisamment soutenu.
Ces indicateurs servent également à réviser les standards. Si plusieurs équipes demandent le même écart, la règle est peut-être obsolète, trop coûteuse ou impossible à appliquer. À l’inverse, une hausse des achats engagés avant revue révèle un circuit trop lent ou des responsabilités mal comprises. La bonne réponse n’est pas automatiquement un comité supplémentaire, mais souvent une instruction plus rapide et des droits plus lisibles.
L’arbitrage final appartient au dirigeant
Les erreurs fréquentes sont prévisibles : exceptions sans date d’expiration, acceptations orales, plans de remédiation sans budget, refus motivés par l’élégance technique, ou escalades si lentes que le projet contourne l’instance. Une autre dérive consiste à laisser l’architecte accepter seul un risque commercial ou cyber qui dépasse son mandat.
L’arbitrage final du DSI tient alors en une question : l’avantage immédiat justifie-t-il une dépendance que l’organisation saura réellement financer, sécuriser et supprimer ? Si la réponse n’est pas démontrée, le refus est une décision de gestion. C’est l’un des principes cohérents avec l’approche de Révolution Numérique ! : relier les choix technologiques à la valeur, au risque, au coût et à la responsabilité. Un comité crédible ne dit pas non pour préserver la pureté d’un modèle. Il dit non lorsque personne ne peut assumer proprement le prix de l’exception.
Pour approfondir
Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon
Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon
#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique
