Avant de poursuivre votre lecture, je vous suggère de vous poser trois questions simples et d’évaluer vos réponses sur une échelle de 0 à 10 :
- Quel est le degré d’autonomie de votre organisation ou de votre écosystème IT ?
- Quel est le degré de résilience de vos services numériques les plus critiques ?
- À quel point êtes-vous certain d’avoir réellement le contrôle ?
Nous opérons tous sous une pression comparable. Nous devons tous faire face à des changements technologiques similaires. Nous sommes confrontés à un besoin de rapidité sans précédent. Nous avons la même responsabilité. Pourtant, nos réponses à ces questions diffèrent probablement. Ou votre réponse est « ça dépend » et, plus probablement encore, « définissez ces trois concepts ». Ma réponse aux trois questions est 0. Je vais vous expliquer pourquoi, et nous verrons si votre score parfait de 10 est toujours justifié.
En tant que CIO, nous restons pleinement responsables des performances, de la continuité, de la sécurité, de la conformité et du budget. En cas de défaillance, la responsabilité est sans ambiguïté. En même temps, l’exécution est désormais profondément répartie : les plateformes, le cloud public, le SaaS, le low-code, les partenaires externes, les systèmes de systèmes basés sur des API et les workflows de plus en plus axés sur l’IA contribuent tous à ce dont nous sommes responsables. L’IT n’est plus non plus le domaine exclusif du service IT. Nous encourageons les unités business à innover et l’organisation en bénéficie clairement. L’écart entre notre responsabilité personnelle et le contrôle réel que nous exerçons sur celle-ci ne cesse de se creuser, et la plupart des tensions liées à notre rôle résident désormais précisément dans cet écart. Qui ne se limite d’ailleurs pas aux CIO.
La perte de contrôle peut commencer par de grandes décisions stratégiques : « transférons tout vers le cloud », « délocalisons », « fusionnons », etc. Cependant, l’érosion ne provient généralement pas de ces moments-là. Elle provient de petits choix rationnels et apparemment inoffensifs pris localement. Ils commencent généralement par « juste » :
- Juste un exercice de debugging qui enregistre un peu plus de données que prévu et finit par être exécuté en production
- Juste une police prise sur Internet qui expose discrètement les adresses IP des utilisateurs
- Juste une optimisation technique pour le stockage d’archives qui multiplie les coûts jusqu’à ce que la facture devienne exorbitante
- Juste un outil que tout le monde commence à utiliser parce qu’il était déjà inclus dans la licence, créant en un mois plus de shadow IT que nous n’en avons supprimé en un an
- Juste un nouveau SaaS par défaut qui enfreint soudainement la conformité, même si personne ne l’a demandé
- Juste une modification de conception qui améliore un composant mais perturbe la haute disponibilité dans toutes les régions
- …
Chacun de ces choix est parfaitement logique pris isolément. Aucun d’entre eux ne résulte d’une mauvaise intention ou d’une incompétence. Pourtant, à grande échelle, des milliers d’entre eux se produisent chaque jour. Et même dans les organisations dotées d’une gouvernance mature, de comités d’architecture, de revues et d’évaluations d’impact, ils peuvent causer des ravages. Lorsque l’on prend du recul, leur fragilité devient évidente. Ces « justes » sont la kryptonite de la gouvernance et du contrôle. Non pas parce qu’ils sont mauvais, mais parce qu’ils sont inévitables et, dans de nombreux cas, essentiels pour que tout continue à fonctionner.
Le changement que nous vivons est tout sauf subtil. Nous ne gérons plus de systèmes simples avec un seul serveur et un seul monolithe. Nous exploitons des écosystèmes et, de plus en plus, des systèmes de systèmes. L’analyse des causes profondes n’est plus une ligne droite allant du symptôme à la cause. Les dépendances sont invisibles, implicites ou tout simplement inconnues. Les attentes en matière de performances sont désormais en temps réel. L’IA agit désormais comme un test de résistance permanent sur l’infrastructure, les flux de données et les modèles opérationnels. La cybersécurité est passée de la protection d’un périmètre à la gestion d’une exposition continue et à la prise en compte des violations. Le cloud public nous offre une vitesse et une échelle sans précédent, tout en créant de nouveaux risques de concentration rendus plus tangibles par les tensions géopolitiques. Les API et les microservices ont fait exploser les graphiques de dépendance à un niveau qu’aucun diagramme d’architecture, et certainement aucun être humain, ne peut pleinement comprendre. Et en plus de tout cela, nous travaillons avec des personnes. La logique binaire ne s’applique pas aux humains, et même si c’était le cas, des décennies d’IT ont démontré que la logique binaire seule n’a jamais été une garantie de fonctionnement parfait d’un système. Et tout cela se produit désormais à des vitesses que nous n’avons jamais eu à gérer auparavant.
Or, une grande partie de nos mécanismes de contrôle ont été conçus pour un monde différent. Le terme VUCA (Volatile, Uncertain, Complex, Ambiguous) existe depuis les années 80, mais il semble qu’il ait fallu attendre 2026 pour le vivre réellement : une crise à la fois, plusieurs par an, parfois en même temps. Les KPI, les principes des quatre yeux, les conseils d’architecture, les politiques documentées et les stratégies classiques de reprise après sinistre supposaient tous des systèmes plus petits, tant en taille qu’en complexité technologique, des lignes de responsabilité plus claires, un comportement prévisible, une échelle modeste et beaucoup moins de dépendances externes.
Un document de politique ne peut empêcher un workflow automatisé de commettre des erreurs à grande échelle. Deux data centers ne vous protègent pas contre les certificats expirés cachés quelque part au cœur de votre écosystème. La connectivité dualpath n’est d’aucune utilité lorsque les deux chemins partagent le même câble sous-marin qui est perturbé. Une haute clôture n’arrête pas un drone.
Les concepts sur lesquels nous nous appuyions au siècle dernier ne sont pas erronés et ne sont pas sans valeur. Ils ne sont tout simplement plus suffisants. Ils doivent être repensés avec soin s’ils veulent rester pertinents dans un monde où la stratégie est quelque chose que l’on réexamine quotidiennement, et non tous les cinq ou dix ans. L’analyse de scénarios était une méthode de planification stratégique à long terme, utilisée une fois toutes les quelques années afin d’explorer des futurs lointains. Aujourd’hui, il vaut mieux le faire tous les mois.
Si la gouvernance veut rester pertinente, elle doit passer d’une approche déclarative à une approche exécutable. Les règles importantes doivent être applicables. La gouvernance doit fonctionner à la vitesse de l’exécution, sinon elle sera simplement contournée. Il ne s’agit pas de centraliser les décisions, d’ajouter des processus lourds ou de créer de nouveaux conseils d’administration. Et il ne s’agit certainement pas d’alourdir la paperasserie. Il s’agit d’être explicite sur les intentions et les éléments non négociables, tout en rapprochant l’exécution de la source, avec les personnes les plus aptes à agir. Et si quelque chose ne peut être automatisé, il faut trouver des moyens de construire et de renforcer une conscience collective qui permette à chacun de rester attentif à ce qui est « bon ».
La résilience doit également être repensée. La redondance n’a guère de sens si l’on ne sait pas quels scénarios de défaillance elle couvre réellement. Aujourd’hui, la résilience est une propriété de l’écosystème. Elle concerne l’identité, les flux de données, les dépendances et les voies de récupération. Elle consiste à savoir si l’on peut reconstruire en quelques jours plutôt qu’en quelques semaines. Elle vise à déterminer si la possibilité d’une disparition numérique a été envisagée dans un monde où tout ce qui compte est numérique. Bon nombre de mécanismes sur lesquels nous nous appuyons encore ont été créés à une époque où les intentions malveillantes étaient l’exception, et non la norme. L’idée d’un « business minimum viable » capable de survivre à une perturbation prolongée n’est plus théorique. Elle est devenue une nécessité.
Les métriques restent importantes, mais il s’agit d’un moyen, pas d’une fin. Lorsque les KPI, les balanced scorecards ou les OKR se figent dans des objectifs rigides, ils perdent leur habilité à diriger. Les indicateurs doivent s’adapter aux évolutions de la réalité. Ce qui importe n’est pas un dashboard parfait, mais plutôt s’il aide à agir à temps. L’observabilité en temps réel et la transparence sont bien plus précieux que les rapports de conformité livrés avec des semaines de retard. Dans des conditions volatiles, il faut savoir se défaire de l’illusion de graphiques parfaits. Si les chiffres sont erronés, incomplets ou ne sont plus utiles, l’historique doit être sacrifié au profit de la précision, même si cela peut faire mal.
L’automatisation et l’IA sont essentielles. La supervision humaine n’est pas évolutive, il convient donc d’utiliser l’IA là où elle excelle et où sa marge d’erreur reste préférable à l’absence totale d’IA. Elle peut détecter des modèles, corréler des signaux faibles et appliquer des règles avec une cohérence que les humains ne peuvent égaler. Cependant, les humains restent essentiels. Non pas en tant que checkpoints, mais en tant que systèmes d’alerte précoce. Ils doivent être capables d’identifier les anomalies avant même qu’une alerte ne se déclenche, et être dignes de confiance et habilités à agir selon leur instinct. Cela nécessite de la clarté, de la confiance et de la répétition. Cela nécessite également des outils qui rendent les signaux visibles, le contexte explicite et permettre l’action en temps utile.
L’objectif n’est peut-être pas de tout contrôler. Cela a toujours été une illusion. L’objectif est de concevoir des organisations où le contrôle se rétablit assez rapidement et assez près de la source lorsque les choses dérapent, échouent ou se comportent de manière inattendue :
- Moins d’illusion de contrôle
- Plus de contrôle applicable
- Moins de commandement centralisé
- Plus de responsabilité collective
C’est le défi auquel beaucoup d’entre nous sont confrontés aujourd’hui. Et aucune organisation ne pourra le relever seule.
Revenons aux trois questions posées plus haut : autonomie, résilience, contrôle.
Quel est votre score maintenant ?
Il s’agit d’une contribution de Dirk Deridder, CTO chez Smals. Elle a été rédigée à titre personnel et ne constitue pas une prise de position au nom de Smals. Vous souhaitez contribuer à des projets et des services ayant un impact positif pour la société ? Consultez nos nombreuses offres d’emploi et découvrez comment vous pouvez faire la différence.