De l’incident déclencheur à l’organisation cible : un récit de transformation IT en quatre actes.
L’IT a construit sa légitimité sur une compétence : traduire les intentions des métiers en logiciels fonctionnels. C’est un rôle que les organisations ont payé cher pendant trente ans, et qui disparaît plus vite qu’on ne le planifie. La vraie question n’est pas comment l’IT va s’adapter. C’est ce que l’IT va produire une fois que sa raison d’être originale n’existe plus. Ce que certaines organisations ont commencé à construire à la place est plus radical, et plus cohérent, qu’on ne l’imagine.
C’est un vendredi après-midi de septembre 2026. Vous découvrez, dans un canal Teams que vous consultez rarement, qu’une équipe commerciale a mis en production un outil de reporting automatisé. L’outil consolide des données issues de trois sources différentes, génère des synthèses hebdomadaires par portefeuille client, et envoie des alertes dès qu’un seuil est franchi.
Vous regardez la date de création du projet dans Github.
Lundi.
Cinq jours.
Votre réaction initiale est bureaucratique. Aucune demande formelle, aucune validation architecture, aucun passage en comité de validation des changements. Vous pensez à la note de gouvernance que vous allez devoir rédiger.
Puis vous regardez l’outil. Il fonctionne. Les utilisateurs l’utilisent. Aucun signalement d’anomalie. La personne qui l’a construit n’est pas ingénieure : c’est une chef de produit. Elle a juste utilisé Claude Code.
Vous fermez Teams. Vous ouvrez votre backlog IT. La fonctionnalité équivalente est en attente depuis sept mois, estimée à douze semaines de développement, bloquée sur une priorisation en cours avec trois équipes.
Vous pourriez écrire la note de gouvernance. Vous ne le faites pas. À la place, vous vous posez une question que vous n’aviez jamais vraiment formulée : si le métier peut faire ça lui-même, quelle est notre utilité à nous, l’IT ?
La réponse honnête prend quelques semaines à construire. Elle est inconfortable.
L’IT fait trois choses, en réalité.
Il traduit. C’est historiquement le cœur du métier : transformer une intention métier en spécification, une spécification en code, du code en tests, des tests en mise en production. Cette chaîne de traduction a justifié l’existence des Business Analysts, des développeurs, des testeurs, des responsables de déploiement, du support de niveau 1 et de niveau 2. Dans votre organisation, ces rôles représentent entre 60 et 70 % des effectifs IT.
Il opère. Il maintient les systèmes en production, gère les incidents, assure la continuité. Une partie est progressivement automatisable : détection, diagnostic, résolution des incidents d’infrastructure. Une autre partie ne l’est probablement pas à moyen terme. Les décisions à impact financier ou réglementaire direct exigent un jugement humain et une traçabilité documentée.
Il gouverne. Il définit qui a le droit de faire quoi sur les systèmes, dans quelles conditions, avec quelle auditabilité. Ce rôle existe dans toutes les organisations IT, mais il est rarement structuré comme une fonction à part entière. Dans la plupart des cas, il est exercé par défaut : par des architectes surchargés, des responsables sécurité avec un périmètre trop large, des comités qui se réunissent trop rarement.
Ce diagnostic a une implication directe. La traduction, la majorité des effectifs, est la partie que les outils d’IA générative compressent le plus vite. Ce que la chef de produit a fait en cinq jours, c’est exactement ce travail de traduction : elle a formalisé son intention en langage naturel et obtenu un logiciel fonctionnel. L’étape de l’intermédiaire a disparu.
L’opération et la gouvernance résistent davantage. Pas parce qu’elles sont à l’abri de l’automatisation, mais parce qu’elles portent des responsabilités que personne ne peut déléguer à un système sans contrôle humain explicite.
La vraie question se reformule. Si la traduction disparaît, quel est le produit de l’IT ? Que fournit-il au métier ?
La réponse n’est pas “moins de choses”. Mais des choses fondamentalement différentes. L’IT cesse d’être un fournisseur de livraisons pour devenir un fournisseur de capacités : des plateformes, des agents, des infrastructures sur lesquelles les métiers et les équipes IT alignées aux métiers construisent directement. Ce déplacement change la nature du travail, les profils requis, et le modèle organisationnel. Il ne se fait pas par ajustement marginal.
Vous présentez le diagnostic au Comex en novembre 2026. La salle est attentive. Le Comex comprend les enjeux IA : il a approuvé les budgets correspondants depuis deux ans. Ce qu’il saisit moins bien, c’est la conclusion que vous en tirez : réduire les effectifs IT de 65 % sur quatre ans, reconfigurer ce qui reste autour de trois piliers de capacité, et créer une fonction de gouvernance des agents qui n’existait pas.
Le DG vous pose la question prévisible : comment annoncez-vous une réduction IT massive alors que la transformation numérique est la priorité du groupe ?
Vous lui répondez que la réduction est la transformation. Que maintenir 200 personnes sur un modèle de traduction qui devient caduc, c’est investir dans quelque chose que l’IA fait mieux et moins cher. Que les 70 personnes qui restent feront un travail structurellement différent : plus exigeant, mieux rémunéré, non substituable à moyen terme.
Le DG valide le plan. Ce n’est pas la partie difficile.
La partie difficile commence avec les équipes.
Votre Tribe Lead gérait une tribu de soixante personnes réparties en cinq squads. Dans le modèle cible, son cluster compte douze personnes, dont quatre profils ne relèvent pas de son management direct : ils appartiennent au pilier AI Engineering, intégrés dans son cluster pour 80 % de leur temps. Sa légitimité organisationnelle s’appuyait en partie sur le périmètre qu’il contrôlait. Il résiste. Pas ouvertement. Il demande des clarifications sur le modèle de gouvernance, soulève des risques de coordination, propose des variantes qui maintiendraient son périmètre intact. Vous reconnaissez le schéma. Vous le nommez clairement dans un entretien individuel : c’est sa propre position dans ce modèle qu’il remet en question. La conversation est difficile. Elle est nécessaire.
Les développeurs sont une autre tension. Certains réussissent la transition vers le rôle d’AI Systems Engineer : ils apprennent à orchestrer des agents, à évaluer des comportements, à concevoir des systèmes qui supervisent d’autres systèmes. La transition prend du temps, et elle demande une capacité d’abstraction qui ne se décrète pas. Votre DRH vous alerte dès le premier semestre 2027 : les profils de niveau intermédiaire, dix ans d’expérience dans un domaine technique spécifique, peinent le plus. Leur compétence centrale est précisément ce qui s’automatise le plus vite : écrire du code propre à leur domaine. La reconversion est possible pour une partie d’entre eux. Pas pour tous. Vous perdez des profils par départ volontaire ou par décision mutuelle. C’est une réalité que le plan assume dès le début, pas une surprise de parcours.
Les métiers créent une tension que vous n’aviez pas anticipée. Ils veulent l’autonomie que le nouveau modèle leur offre : construire leurs propres outils, définir leurs propres agents. Mais ils résistent à la contrepartie : prendre en charge la responsabilité de ces outils. Quand un outil construit hors supervision IT génère une anomalie de données ou une erreur de calcul, la question de la responsabilité devient floue. Vous imposez une règle simple dès 2027 : tout outil qui touche un système d’information critique ou un flux réglementaire passe par un processus de validation IT. Pas de livraison : de certification. L’IT ne construit plus ce que les métiers peuvent construire eux-mêmes. Il certifie que ce qu’ils ont construit est sûr. La règle crée des frictions la première année. Elle évite des incidents significatifs les suivantes.
Le régulateur est une contrainte que vous n’avez pas choisie, mais qui se révèle structurante. Les obligations de contrôle humain documenté sur les décisions à fort impact limitent l’autonomie des agents sur certains flux : surveillance des abus de marché, reporting réglementaire. Ces contraintes obligent votre organisation à construire une gouvernance explicite là où il n’y avait que de l’implicite. En 2029, cette gouvernance est un actif. Elle est ce qui permet à vos agents de fonctionner sans que le régulateur ne les remette en cause.
Votre organisation IT compte maintenant 70 personnes. Elle en comptait 200 en 2026.
Ce qui a fortement réduit : le support de niveau 1 et de niveau 2, automatisé à environ 80 % pour les incidents d’infrastructure et de données dans votre contexte. Les testeurs dédiés, dont les tâches sont désormais générées et exécutées en continu par des agents. Les responsables de déploiement, remplacés par un processus continu avec des points de validation automatisés. Les Scrum Masters et coordinateurs de portefeuille, dont l’orchestration des workflows est automatisée. Les opérateurs de réconciliation manuelle : les exceptions sont détectées, catégorisées et traitées sans intervention humaine dans la grande majorité des cas.
Ce qui reste est organisé en trois piliers.
Domain Intelligence, 35 personnes. Ce sont les profils qui détiennent la connaissance métier qu’aucun agent ne peut acquérir par entraînement. Pas des développeurs : des spécialistes de domaine qui savent ce qu’un agent de valorisation doit faire dans un marché disloqué, ce qu’une règle réglementaire implique dans un cas limite non formalisé, ce qu’un signal d’anomalie signifie dans le contexte spécifique de votre organisation.
Les 35 sont répartis en six clusters d’expertise de quatre à six personnes. Ce découpage répond à deux contraintes précises. La première est la résilience : sur chaque domaine critique, au moins deux personnes partagent la même connaissance tacite. Le risque de dépendre d’un seul porteur de savoir a disparu du modèle. La deuxième est la transmission : les profils seniors spécifient, valident et traitent les escalades. Les profils juniors observent, questionnent, prennent en charge des périmètres étroits jusqu’à maîtriser l’ensemble. C’est un modèle de compagnonnage, le nouveau peer programming.
Chaque cluster couvre un périmètre fonctionnel plus large que les anciennes squads. Une squad sur le modèle Spotify était construite autour d’un flux précis. Un cluster Domain Intelligence couvre un domaine entier, avec ses variantes et ses cas limites. Les agents gèrent les cas standards. Les humains gèrent les cas que les agents ne savent pas reconnaître comme exceptionnels.
Leur travail n’est plus d’écrire du code. C’est de spécifier avec précision les comportements attendus des agents, de valider leurs sorties, et de traiter les escalades qu’ils ne peuvent pas résoudre seuls. Ce rôle est plus exigeant que celui de développeur, pas moins.
AI Engineering Platform, 20 personnes. C’est la seule ligne de votre organisation qui a augmenté depuis 2026, en proportion comme en valeur absolue.
Leur travail s’organise autour de trois responsabilités. La première est la construction de l’infrastructure agentique commune : les schémas d’orchestration que tous les clusters utilisent, les processus de déploiement et de retour arrière en production, les interfaces avec les modèles de langage externes. Chaque cluster Domain Intelligence s’appuie sur ces briques. Personne ne reconstruit les siennes. La deuxième est l’observabilité : le suivi comportemental du parc d’agents en production, les mécanismes de coupure automatique quand un agent dérive au-delà d’un seuil défini, les tableaux de bord qui permettent de détecter les anomalies avant qu’elles deviennent des incidents. La troisième est l’évaluation : des cadres de test qui qualifient le comportement d’un agent avant sa mise en production, pas seulement ses performances techniques, mais ses sorties sur des cas limites métier définis par les clusters Domain Intelligence.
Ces profils ne sont rattachés à aucun domaine métier spécifique. Ils servent tous les clusters du premier pilier. En 2026, ils étaient éparpillés dans des fonctions secondaires. C’est devenu le pilier central.
Data & Intelligence, 10 personnes. Leur travail est le moins visible de l’organisation. C’est aussi le plus structurant.
Ils maintiennent les pipelines qui alimentent les agents en données à jour, avec les contrôles de qualité qui détectent les anomalies à la source plutôt qu’en sortie d’agent. Ils formalisent les contrats entre les producteurs de données et les agents qui les consomment : qui produit quoi, à quelle fréquence, dans quel format, avec quelle garantie de fraîcheur. Ce travail de formalisation est récent. Avant 2026, les données circulaient de manière informelle et les ambiguïtés se résolvaient dans les réunions. Il a fallu tout formaliser.
Ils maintiennent aussi l’infrastructure qui permet aux agents d’accéder à la mémoire organisationnelle : les décisions passées, les incidents documentés, les configurations historiques. Un agent de valorisation qui ne sait pas ce qui s’est passé sur un sous-jacent le mois dernier prend des risques que ses paramètres ne capturent pas. Cette mémoire ne se construit pas automatiquement. Elle s’entretient.
Cinq personnes supplémentaires constituent la gouvernance transverse : qui a le dernier mot sur un agent en production, dans quelles conditions on le coupe, comment on documente les décisions pour le régulateur, qui porte la responsabilité quand un agent dérive.
La seule ligne qui a crû est celle qui supervise, évalue, et gouverne des systèmes intelligents. Pas celle qui écrit du code face au métier.
Ce déplacement dit tout sur ce qu’est devenu le produit de l’IT.
L’incident du vendredi après-midi s’est déjà produit dans votre organisation, ou il se produira dans les mois à venir.
Ne vous demandez pas comment encadrer le Shadow IT qui en découle. Répondez plutôt à la seule question qui compte : si le métier peut se passer de votre traduction, quel est le produit de l’IT ?
Répondre honnêtement implique de reconvertir ceux qui peuvent l’être, de se séparer de ceux qui ne le peuvent pas, et de construire quelque chose de structurellement différent. C’est une redéfinition de périmètre.
Les organisations qui le font maintenant construisent quelque chose. Les autres se feront grignoter par leur propre métier, flux par flux, sans que personne ne le décide vraiment.
Ça me rappelle une histoire de grenouille dans une casserole…
