Cloud
Quand le cloud tue la compétence
Par Thomas Chejfec, publié le 23 mars 2026
Le piège du cloud n’est pas dans sa promesse, mais dans le confort qu’elle installe. Quand tout fonctionne par abstraction, la vitesse progresse, mais la maîtrise recule et la DSI glisse d’architecte du système à simple intégratrice de services.
Parole de DSI / Par Thomas Chejfec, Directeur des systèmes d’information
Je vais le dire franchement et sans précaution inutile : le cloud a tué la compétence. Ce n’est pas que les équipes seraient devenues mauvaises ou paresseuses.
Mais nous avons progressivement accepté de remplacer la compréhension profonde des systèmes par la consommation efficace de services, et cette substitution s’est faite sans véritable débat stratégique.
Nous avons tous basculé vers le cloud pour de bonnes raisons, car il permet d’aller plus vite, de réduire le capex, d’expérimenter sans immobiliser des budgets lourds et d’aligner l’IT sur le rythme du business. Mais avec cette accélération, nous avons aussi accepté que la complexité soit déplacée hors de notre périmètre visible : elle n’a pas disparu, mais elle est désormais encapsulée dans des couches techniques que nous n’explorons plus vraiment.
Aujourd’hui, presque tout est managé et abstrait, qu’il s’agisse des bases de données, du réseau, de la sécurité ou de l’observabilité. Cette abstraction permanente donne l’impression d’une maîtrise renforcée alors qu’elle traduit en réalité un éloignement progressif du socle technique sur lequel reposent nos applications critiques : nous savons provisionner, scaler et automatiser, mais nous savons de moins en moins expliquer précisément les mécanismes internes qui rendent ces opérations possibles.
Le problème ne réside pas dans l’efficacité opérationnelle, qui est indéniable, mais dans le fait que nos équipes évoluent, de plus en plus capables d’orchestrer des briques puissantes, mais sans nécessairement comprendre leur fonctionnement intime. Ce mouvement transforme la DSI en intégratrice sophistiquée plutôt qu’en architecte pleinement consciente des forces et des fragilités de son propre système.
Cette fragilité devient visible le jour où l’incident ne se produit plus au niveau de votre code ou dans votre configuration, mais dans une couche technique interne à votre fournisseur. À ce moment précis, vous réalisez que le système que vous surveillez repose sur des mécanismes profonds et des arbitrages techniques que vous ne maîtrisez plus, et que votre capacité d’action réelle se limite à communiquer, à attendre et à adapter votre discours.
On parle souvent de dépendance contractuelle ou technologique, mais le véritable risque est cognitif. Lorsque l’organisation ne sait plus concevoir une architecture en dehors des cadres proposés par son hyperscaler et qu’elle ne possède plus en interne la profondeur technique nécessaire pour challenger ou redessiner ces choix, cela signifie qu’elle a externalisé non seulement son infrastructure, mais une partie de son intelligence technique.
Le cloud n’est certes pas l’ennemi et il serait absurde de prétendre revenir en arrière, mais une DSI qui veut jouer un rôle stratégique pour son entreprise ne peut pas se contenter d’être une excellente consommatrice de services. Elle doit aussi rester capable de comprendre ce qu’elle utilise, de remettre en question ses dépendances et conserver une capacité réelle de réversibilité. Sans ces exigences, la transformation numérique n’est plus qu’une dépendance confortable, et pas du tout un levier maîtrisé.
La question n’est donc pas de savoir si vous êtes cloud native – cette étiquette est désormais devenue banale – mais de déterminer si vous êtes encore capables d’exister en dehors de cet environnement, de concevoir autrement et de décider sans contrainte implicite. Si la réponse est négative, alors le cloud n’a pas seulement transformé votre infrastructure, il a aussi réduit votre liberté stratégique, et cela devrait inquiéter toute direction qui prétend piloter le numérique avec ambition et en responsabilité.
À LIRE AUSSI :
À LIRE AUSSI :
