L'iatrogénie informatique : quand les solutions numériques finissent par créer leurs propres maladies
L'iatrogénie informatique apparaît quand les solutions censées simplifier, sécuriser ou automatiser le SI finissent par créer plus de complexité qu'elles n'en retirent.
L’iatrogénie est un concept issu du monde médical. Elle désigne les effets indésirables provoqués non pas par la maladie elle-même, mais par le traitement censé la soigner. Un médicament peut provoquer une complication. Une intervention peut créer une nouvelle pathologie. L’accumulation de traitements peut finir par fragiliser un patient au lieu de l’aider.
L’informatique connaît, à sa manière, le même phénomène.
Depuis des années, les entreprises ajoutent des technologies, des plateformes, des processus, des contrôles et des couches d’abstraction afin de résoudre des problèmes parfaitement réels. Il faut mieux sécuriser les applications, accélérer les mises en production, améliorer la résilience, faciliter le travail des développeurs, réduire les coûts ou encore automatiser les opérations. Chaque initiative, prise isolément, peut être pertinente. Pourtant, lorsqu’on observe le système dans son ensemble, un paradoxe apparaît : les solutions mises en place pour réduire la complexité deviennent parfois elles-mêmes une source majeure de complexité.
C’est ce que l’on pourrait appeler l’iatrogénie informatique.
Elle apparaît lorsqu’une intervention technique ou organisationnelle produit de nouveaux dysfonctionnements dont la gestion devient progressivement aussi importante que le problème initial. Le système n’est pas nécessairement mal conçu. Les technologies utilisées peuvent parfaitement fonctionner. Mais leur accumulation, leurs interactions et les processus créés autour d’elles finissent par générer de nouveaux risques, de nouvelles dépendances et de nouveaux coûts.
Prenons un exemple très simple.
Une organisation rencontre des problèmes de sécurité. Elle décide d’ajouter un nouvel outil de contrôle. Rapidement, cet outil génère des alertes qu’il faut qualifier. Des règles doivent être maintenues. Des exceptions apparaissent. Les développeurs doivent apprendre à interpréter les résultats. Une équipe centralisée est créée pour gérer les politiques et les dérogations. Un workflow d’approbation devient nécessaire. Puis un second outil est introduit pour agréger les alertes produites par les différents systèmes de sécurité.
Quelques années plus tard, l’entreprise dispose d’un environnement techniquement plus riche mais dont la compréhension et l’exploitation nécessitent une énergie considérable.
Aucune des décisions prises n’était nécessairement mauvaise. Le problème vient de leur effet cumulatif.
C’est probablement l’un des paradoxes les plus intéressants de l’informatique moderne. Nous n’avons jamais disposé d’autant de technologies conçues pour simplifier notre métier, et pourtant la complexité ressentie par les équipes continue souvent d’augmenter.
Le cloud devait nous libérer de la gestion de l’infrastructure. Il nous a effectivement apporté une puissance et une souplesse considérables. Mais il a également introduit de nouveaux sujets : gouvernance, identités, politiques, réseaux virtuels, FinOps, landing zones, sécurité cloud et une quantité impressionnante de services à comprendre et à maîtriser.
Les microservices devaient nous permettre de découpler les applications. Ils ont parfois remplacé un monolithe complexe par des dizaines de services distribués dont les dépendances, les flux réseau et les modes de défaillance sont beaucoup plus difficiles à appréhender.
Kubernetes devait standardiser le déploiement des applications. Il a rempli cette mission, mais il a également créé tout un univers de nouvelles abstractions : clusters, operators, controllers, CRD, ingress, service meshes, politiques et chaînes de configuration.
DevSecOps devait rapprocher sécurité et développement. Dans certaines organisations, il a surtout multiplié les scanners, les alertes et les règles jusqu’à rendre difficile la distinction entre un risque réellement critique et un bruit opérationnel permanent.
Et aujourd’hui, l’intelligence artificielle pourrait bien devenir le prochain chapitre de cette histoire.
Nous utilisons déjà l’IA pour générer du code, analyser des incidents, synthétiser de la documentation, traiter des alertes ou automatiser des opérations. Ces usages peuvent apporter énormément de valeur. Mais ils posent également une question rarement formulée : sommes-nous en train d’utiliser l’intelligence artificielle pour supprimer la complexité ou simplement pour rendre cette complexité supportable ?
La nuance est importante.
Une organisation qui génère cinquante mille alertes inutiles par jour peut construire un système d’IA extrêmement sophistiqué pour les analyser et les prioriser. Elle peut également se demander pourquoi elle produit cinquante mille alertes inutiles.
Dans le premier cas, l’intelligence artificielle traite le symptôme. Dans le second, l’organisation s’attaque à la cause.
Cette différence pourrait devenir déterminante dans les prochaines années.
L’iatrogénie informatique ne naît cependant pas uniquement de l’accumulation des outils. Elle apparaît également à travers les abstractions que nous créons. L’abstraction est évidemment indispensable en informatique. Elle permet de masquer une partie de la complexité et de rendre les systèmes utilisables par des personnes qui n’ont pas besoin d’en comprendre tous les détails.
Mais l’abstraction ne détruit pas la complexité. Elle la déplace.
Tant que tout fonctionne, cette complexité reste invisible. Lorsqu’un incident survient, elle réapparaît brutalement.
Un développeur utilise par exemple une plateforme interne pour déployer une application. Son expérience quotidienne est très simple : quelques paramètres, une action de déploiement et l’application est disponible. Mais lorsque le message "Deployment failed" apparaît, la situation change complètement. Derrière cette simple erreur peuvent se trouver Terraform, Kubernetes, Azure Policy, une identité managée, un secret expiré, une règle réseau ou encore un problème de quota.
La plateforme a simplifié l’usage du système. Elle n’a pas nécessairement simplifié son diagnostic.
Le même phénomène existe dans les organisations. Chaque incident ou chaque risque conduit naturellement à ajouter un nouveau mécanisme de contrôle. Une validation supplémentaire. Une approbation. Une règle de sécurité. Un comité. Un workflow.
Progressivement, l’organisation construit un système extrêmement protecteur sur le papier mais de plus en plus difficile à utiliser dans la réalité.
Les équipes cherchent alors des raccourcis.
Elles créent des scripts parallèles. Elles contournent certaines validations. Elles conservent des comptes techniques. Elles construisent des processus informels qui permettent simplement de continuer à travailler.
Et l’on aboutit à un paradoxe particulièrement intéressant : un mécanisme conçu pour réduire le risque peut finir par provoquer les comportements risqués qu’il voulait précisément éviter.
L’automatisation peut également amplifier ce phénomène.
Pendant longtemps, une mauvaise décision opérationnelle restait limitée par la vitesse à laquelle un humain pouvait l’exécuter. Avec l’automatisation et, demain, avec les agents autonomes, cette limite disparaît.
Un humain peut effectuer quelques dizaines d’actions incorrectes avant qu’une équipe ne réagisse. Un système automatisé peut en effectuer plusieurs milliers en quelques minutes.
Cela ne signifie évidemment pas qu’il faut renoncer à l’automatisation. Au contraire. Mais plus nous automatisons, plus certaines propriétés deviennent essentielles : l’observabilité, la capacité à comprendre une décision, la réversibilité et la limitation du rayon d’impact.
La bonne question n’est donc plus uniquement : "L’agent est-il capable d’effectuer cette tâche ?"
Elle devient aussi : "Que se passe-t-il lorsqu’il se trompe ?"
Cette question pourrait devenir centrale dans l’ingénierie des systèmes agentiques.
Il existe enfin une forme d’iatrogénie plus discrète mais tout aussi puissante : celle provoquée par les métriques.
Nous introduisons une mesure pour encourager un comportement. Puis, progressivement, l’organisation commence à optimiser la mesure plutôt que le résultat réel.
Nous mesurons le nombre de déploiements et les équipes cherchent à déployer davantage. Nous suivons le nombre de vulnérabilités corrigées et les équipes maximisent les tickets fermés. Nous mesurons le volume de code généré avec l’IA et nous finissons par produire davantage de code.
La métrique, conçue comme un outil d’amélioration, influence alors le système qu’elle était censée simplement observer.
Autrement dit, le traitement modifie le patient.
Cette idée devient particulièrement importante lorsque l’on observe la manière dont nous traitons les incidents informatiques.
Notre culture d’ingénierie nous pousse souvent à rechercher une "root cause", une cause racine unique capable d’expliquer l’incident. Cette approche reste utile, mais elle montre ses limites dans les systèmes distribués complexes.
De nombreux incidents modernes ne proviennent pas d’un composant défectueux. Ils apparaissent à partir d’une combinaison de conditions qui, prises isolément, sont parfaitement normales.
Une configuration légèrement différente. Une saturation inhabituelle. Une latence réseau. Un mécanisme de retry. Une dépendance externe. Une automatisation qui réagit trop rapidement.
Aucun élément ne suffit seul à provoquer l’incident. C’est leur interaction qui produit la panne.
Chercher uniquement "le composant responsable" revient alors un peu à chercher l’organe coupable lorsqu’une maladie concerne en réalité le fonctionnement de l’organisme entier.
Cette perspective change profondément le rôle de l’architecture et, plus largement, celui du CTO.
Le travail ne consiste plus seulement à sélectionner et à introduire de nouvelles technologies. Il consiste aussi à comprendre les effets secondaires qu’elles produiront dans le système.
Avant d’introduire une nouvelle plateforme, un nouvel outil ou une nouvelle automatisation, il faudrait donc poser quelques questions simples.
Quel problème cherchons-nous réellement à résoudre ? Quelle complexité cette solution va-t-elle supprimer ? Quelle nouvelle complexité va-t-elle introduire ? Qui devra l’exploiter dans trois ou cinq ans ? Quelles dépendances nouvelles allons-nous créer ? Et surtout : comment saurons-nous, un jour, que nous n’en avons plus besoin ?
Cette dernière question est probablement l’une des moins posées dans les projets informatiques.
Nous savons très bien ajouter.
Nous savons beaucoup moins bien retirer.
La médecine possède pourtant une notion intéressante : la déprescription. Lorsqu’un patient accumule les traitements, les médecins peuvent réexaminer leur utilité, supprimer ceux qui ne sont plus nécessaires et simplifier la prise en charge.
L’informatique aurait probablement besoin d’une discipline équivalente.
Une démarche qui ne demanderait pas uniquement : "Quelle nouvelle technologie devons-nous adopter ?"
Mais aussi : "Que pouvons-nous supprimer ?"
Une plateforme devenue inutile. Une couche d’abstraction redondante. Un outil qui fait doublon. Une validation qui n’apporte plus de valeur. Une technologie que seules deux personnes comprennent encore. Un processus créé pour résoudre un problème qui n’existe plus.
Dans beaucoup d’organisations, supprimer un composant est considéré comme une opération de maintenance. Cela devrait parfois être considéré comme un acte d’architecture.
Le Platform Engineering peut d’ailleurs jouer ici un rôle extrêmement intéressant.
On présente souvent les Internal Developer Platforms comme des outils permettant d’accélérer les développeurs. Mais leur valeur la plus stratégique pourrait être ailleurs : réduire l’exposition des équipes à la complexité accidentelle du système.
Un développeur ne devrait pas avoir besoin de devenir expert en Kubernetes, Terraform, Azure Policy, Entra ID, réseau, observabilité et FinOps simplement pour mettre une API en production.
Un bon golden path ne consiste pas seulement à ajouter une nouvelle interface devant cette complexité. Il doit réellement supprimer des décisions inutiles, standardiser des choix et rendre les comportements par défaut suffisamment bons pour la majorité des situations.
Mais là encore, le remède peut devenir iatrogène.
Une plateforme interne peut elle-même devenir une énorme machine difficile à maintenir, comprise uniquement par quelques spécialistes et tellement abstraite que les utilisateurs deviennent incapables d’en diagnostiquer les incidents.
La question n’est donc jamais simplement de choisir une technologie. Il faut continuellement observer les effets qu’elle produit sur l’ensemble du système.
Peut-être devrions-nous d’ailleurs commencer à mesurer davantage la santé de nos systèmes informatiques, et pas seulement leur performance.
Combien de concepts un développeur doit-il maîtriser pour effectuer une tâche simple ? Combien d’équipes doivent intervenir pour modifier un composant ? Combien de temps faut-il pour comprendre un incident avant même de commencer à le résoudre ?
Ces questions disent parfois beaucoup plus sur la qualité d’un système que le nombre de déploiements quotidiens ou la disponibilité d’une plateforme.
L’iatrogénie informatique nous invite finalement à changer légèrement notre regard sur la technologie.
Tous les problèmes informatiques n’ont pas besoin de davantage d’informatique.
Toutes les difficultés opérationnelles ne nécessitent pas un nouvel outil.
Toutes les complexités ne doivent pas être masquées par une abstraction.
Et toutes les tâches humaines ne doivent pas nécessairement être automatisées.
L’IA va probablement accélérer encore cette réflexion. Car elle nous donne désormais la possibilité de construire des systèmes capables de compenser une complexité gigantesque. Des agents pourront naviguer dans des environnements que plus aucun humain ne pourra comprendre entièrement.
La tentation sera grande de considérer cette capacité comme une solution.
Mais il faudra rester vigilant.
Une entreprise capable de gérer une complexité infinie grâce à l’IA n’aura pas nécessairement construit un meilleur système.
Elle aura peut-être simplement construit un système trop complexe pour fonctionner sans IA.
C’est toute la différence entre traiter les symptômes et soigner le patient.
Dans les prochaines années, l’une des compétences les plus importantes pour les architectes, les équipes plateforme et les CTO ne sera donc peut-être pas de savoir quelle technologie ajouter.
Ce sera de comprendre quand une technologie améliore réellement le système, quand elle ne fait que masquer ses dysfonctionnements et, parfois, quand le meilleur choix consiste simplement à ne rien ajouter.
Car la maturité technologique ne se mesure pas seulement à ce qu’une organisation est capable de construire.
Elle se mesure aussi à ce qu’elle est capable de simplifier.