Transformer son organisation tech pour la rendre AI-driven

Ce qui change quand construire coûte moins cher que décider

Créer une équipe AI-native à quatre personnes est facile. Le problème, c'est quand on en a déjà quatre-vingts personnes ou plus dans nos équipes : comment repenser nos organisations à l'ère de l'IA ?

Tant que construire prenait des semaines, quelques jours de specs, d'alignement et de handoffs se fondaient dans le cycle. Quand la construction tombe à quelques jours, ces mêmes délais deviennent le cycle. L'IA challenge les organisations actuelles, centrées sur un temps de delivery long. Ce problème étant en partie résolu, comment s'adapter et mettre en place des organisations efficaces ?

Ce qui change dans les équipes

À dix personnes, même dans une seule squad, beaucoup d'interfaces ont besoin d'être formalisées. « Qui prend ça ? » devient un ticket Jira. « Il faut aligner les parties prenantes » devient une réunion. À trois ou quatre, ces mêmes interactions cessent souvent d'avoir besoin d'un process. « Tu prends ça ? » est une phrase. « Attends, viens voir » remplace la réunion d'alignement. On ne supprime pas la coordination. On réduit son coût transactionnel.

Petit à petit, on voit émerger un format différent, la one pizza team. Une personne dont le rôle est de comprendre et de diffuser le besoin client, de vérifier l'impact de ce qui est développé, pas forcément un PM, qui peut prototyper. Deux ou trois autres pour aider au prototype ou pour industrialiser et faire évoluer le produit. Pas forcément les mêmes rôles, mais toujours dans une équipe à taille réduite. Et à mon avis, jamais une seule personne avec des agents : multiplier les agents ne crée pas la diversité de jugement de plusieurs humains responsables du résultat, l'intelligence collective reste nécessaire.

Chaque étape du cycle produit pose alors une question simple : est-ce qu'elle ajoute du jugement, ou est-ce qu'elle transporte de l'information ? Client, PM, spec, ticket, dev, review, QA. Quand on supprime les étapes de pur transport, une équipe plus petite devient viable. C'est la suppression qui permet la réduction, pas l'inverse.

Dans beaucoup d'organisations, surtout celles où la culture produit est faible, les développeurs vivent derrière le PM. Specs entrantes, code sortant, jamais un client. Quand les étapes de transport se compriment, les développeurs se retrouvent exposés au besoin réel : pourquoi une feature est demandée, dans quel contexte, avec quelle urgence. La transformation est plus simple quand les silos sont faibles, que les devs connaissent leurs clients et leurs besoins, sont déjà capable d'absorber une partie de la QA, mais elle n’est pas facile pour autant.

Pourquoi c'est difficile

Dès qu'une équipe de trois peut absorber une partie du travail qui en mobilisait huit, la question arithmétique se pose. Et c'est une réponse compliquée à creuser. Une hausse de capacité peut aller vers moins de headcount, vers plus de produit construit, plus de qualité ou vers un déplacement des compétences. C'est le choix du CEO. Mais commencer par le headcount comporte un risque : figer la nouvelle organisation avant d'avoir compris où la valeur humaine s'est déplacée. Supprimer aujourd'hui les gens dont on découvrira six mois plus tard qu'ils étaient excellents pour comprendre les clients, arbitrer ou maintenir du contexte (coucou à Klarna, Ford et les autres).

Et le headcount n'est finalement pas le point le plus complexe des transitions IA.

Dans une organisation, le statut suit souvent la rareté. Celui qui sait faire ce que les autres ne savent pas faire devient indispensable, puis senior, puis lead ou manager. L'IA ne supprime pas cette expertise, mais elle change ce qui est rare. Quand certaines capacités techniques deviennent accessibles à beaucoup plus de monde grâce aux agents, ce n'est pas la compétence qui disparaît, c'est son monopole organisationnel. Le back-end engineer n'est plus nécessairement le seul capable de toucher au back. Le senior n'est plus le seul capable de produire rapidement un prototype complexe. Le PM n'est plus le seul capable de transformer une conversation client en première matérialisation du besoin. Ça n'empêche pas que l'expertise est toujours aussi utile, juste que l'impact de l'expert étant également multiplié, le ratio expert/généraliste peut diminuer.

Le rôle du manager bouge lui aussi. Dans une cellule de trois ou quatre personnes, il y a moins de travail quotidien de distribution et de synchronisation. Le manager ne disparaît pas pour autant : le périmètre change. Il passe de l'optimisation de l'équipe à l'optimisation du système entre les équipes. Créer le contexte qu'une cellule ne peut pas produire seule, gérer les dépendances, déplacer les personnes et les compétences là où elles ont le plus de valeur, accompagner des rôles qui changent plus vite que les fiches de poste. C'est un changement de métier, pas une augmentation du nombre de personnes à manager.

Ce changement est facile à écrire dans un article de blog, mais moins quand on est confronté à la réalité. Un développeur senior a parfois passé quinze ans à devenir excellent dans une compétence que les agents rendent soudain accessible à d'autres. Lui dire « maintenant, parle au client, orchestre des agents et sois polyvalent » est facile à dire, mais est bien plus complexe à vivre. C'est une remise en cause de la source même de sa confiance professionnelle.

Une partie de ce que l'on va appeler « résistance au changement » ne sera pas du conservatisme technologique. Ce sera la réaction rationnelle de gens dont la place dans l'organisation reposait sur une rareté qui disparaît. D'où l'importance de planifier et de structurer ce changement.

Comment y aller

On ne fait pas une transition IA juste en redessinant un organigramme. On prend un flux produit réel, on réduit les interfaces qui transportent de l'information sans ajouter de jugement, on outille avec des agents, et on observe ce qui casse. On commence par une équipe : avant de tout impacter, on apprend, puis on déploie.

Les blocages apparaissent vite : un PM qui n'arrive pas à lâcher la rédaction de specs, un développeur qui ne sait pas quoi demander à un client, un manager qui continue à coordonner une cellule qui n'a plus besoin de lui pour se coordonner. Parfois c'est la compétence technique qui manque, parfois c'est la compréhension métier.

C'est là qu'on forme, pas avant, et sur le point de friction réel plutôt que sur des compétences génériques. Former tout le monde au prompt engineering avant de changer le flux de travail, c'est reproduire l'ancien modèle avec des outils plus rapides. La transformation commence quand on change le flux lui-même. Puis on recommence sur un autre flux.

Je ne sais pas encore à quoi ressemble l'état stable. Aucune des organisations que j'observe n'y est arrivée, y compris celles qui avancent vite. Ce que je vois, c'est que celles qui progressent ne cherchent pas le bon organigramme. Elles raccourcissent le chemin entre un problème client et le moment où l'équipe apprend si elle l'a résolu. Elles expliquent les apprentissages et accompagnent les changements. Les capacités des outils bougent plus vite que les fiches de poste. Sur ce chemin, chaque interface doit justifier le jugement qu'elle ajoute.