Quand une partie de l'organisation accélère

Entre avril et mai 2026, je suis allé à la rencontre de plus de vingt Octos — Product Owners, designers, développeurs, commerciaux, Ops, Tech leads, architectes — pour comprendre comment l'IA transformait leurs pratiques. Un an plus tôt, j'en avais interviewé treize. Ce que vous allez lire est la synthèse de leurs victoires, de leurs doutes et parfois de leurs épuisements.

Cet article s'adresse à celles et ceux qui managent, accompagnent ou travaillent avec des équipes en train d'adopter ces outils, et qui se demandent ce que ça fait au collectif autour. Pour structurer mon récit, j'ai utilisé l'IA comme un sparring partner conceptuel, appliquant à ma propre écriture ce tempo hybride entre vélocité technologique et maturation humaine. Pour la relecture finale, j'ai fait appel à des collègues humains ;-), j'ai annoté des passages où j'avais des doutes, où j’avais besoin de réponses de pairs, …

Disclaimer : J'utilise le terme IA pour parler de l'intelligence artificielle générative.

En 2026, l'ingénierie logicielle a franchi un point de rupture : le goulet d'étranglement culturel historique qu'était la vitesse d'écriture du code a sauté. Cela déplace les contraintes de la technique vers l'organisation humaine et redéfinit, finalement, profondément nos métiers et les relations entre ces métiers.

Du paysage de 2025 aux réalités de 2026

Entre septembre et octobre 2025, l'observation de 13 Octos confrontés à l'IA avait posé les bases d'une première réflexion sur l'évolution de mon métier de coach orga. L'impact de ces outils sur la création de code ou de maquettes était tel qu'il imposait déjà de réinventer nos méthodes de management d'équipe. Pourtant, lorsque j'ai partagé la photo de ce paysage au printemps 2026, le constat était sans appel : le terrain avait déjà bougé. Les questions du public étaient systématiquement "et aujourd'hui, qu'en est-il ?". Cette impression collective d'une accélération fulgurante m'a poussé à retourner sur le terrain. Entre avril et mai 2026, j'ai mené plus de vingt nouvelles interviews pour croiser les regards de l'ensemble de l'écosystème Produit et Tech et constater l'évolution.

L'essentiel en un coup d'œil

Premier constat : l'IA n'est plus un outil de développeurs

Chez OCTO, l'année 2026 marque la fin de la quasi-exclusivité des profils techniques sur les outils d'intelligence artificielle. On assiste à une émergence majeure dans les rôles de designers, de Product Owners, de business developer, chacune et chacun s'appropriant ces technologies pour repenser des activités de leurs métiers respectifs.

Chez les designers, l'IA permet d'absorber l'exécution graphique et permet, par exemple pour un UI designer, de montrer des prototypes interactifs lors d'avant-vente avec nos clients. Une autre Designer s'est appuyée sur l'outil pour la phase suivant la recherche utilisateur : "On a fait la phase de discovery [...]. puis un design sprint. Et à l'issue, on avait des intentions de fonctionnalité. Et j'ai demandé à Claude et à Figma Make de me générer une maquette à partir de ça. Ça m'a généré tout un prototype développé."

Les profils des commerciaux transforment également leurs pratiques. Un business developer me racontait l'automatisation de la gestion de ses réunions (enregistrement de la réunion, transcripts des audios et génération de comptes-rendus directement sur le Drive) et son utilisation de l'IA comme un partenaire de confrontation pour optimiser ses propositions commerciales. Il résume ainsi ce gain d'opportunités : "ça me donne du temps de cerveau disponible pour me focaliser sur les bons sujets."

En amont du code, l'IA s'impose pour traiter la masse d'informations qualitatives. Une Product Designeuse donne un exemple : "Nous avons mis toutes nos notes dans Perplexity. Et nous posions les questions et il allait chercher que dans nos notes et pas sur Internet. [...] pour m'aider à analyser des entretiens, à construire ma restitution, à compter le nombre d'occurrences (ndlr. de chaque thématique)".

Parallèlement, les interfaces traditionnelles de création commencent à être bousculées par la nouvelle génération. Une designeuse de retour d'un long congé observe l'évolution fulgurante des outils graphiques et anticipe de fortes ruptures : "Je viens d'ouvrir Claude Design pour voir à quoi ça ressemble, et je pense que ça va tuer Figma, etc.". À voir.

Côté technique, le paradigme de l'assistant textuel à qui l'on posait des questions isolées s'efface au profit d'environnements agentiques. Les développeurs et tech leads délèguent dorénavant des pans entiers de Production à des agents capables d'itérer en autonomie. L'un d'eux témoigne de cette bascule opérationnelle : "Je pense que Claude Code est meilleur que 95% des développeurs du monde. [...] On le pilote, on fait des plans, beaucoup, et après on le laisse coder. On ne revoit plus (ndlr. le code)."

Et avec encore plus de détails : "dans mon projet, je lui dis que tout doit être testé, que la couverture de tests ne soit pas baissée, … Il propose un plan. Je regarde toutes les étapes. Si c'est bon, je lui dis « Ok, vas-y, implémente ». Il implémente, il teste et moi, je valide fonctionnellement. Je ne valide pas le code. Ensuite, je passe en mode audit : je quitte ma session, en ouvre une nouvelle et demande : « Je veux que tu fasses un audit de code en termes de sécurité, de performance, … » il fournit un plan pour me montrer ce que je pourrais améliorer. Il fait l'audit."

L'ingénierie logicielle monte même d'un niveau d'abstraction avec l'utilisation de plateformes comme BMAD. Un utilisateur décrit une sophistication inédite où les agents sont utilisés pour s'auto-améliorer : "Le produit, en fait, c'est des poupées russes. On fait un produit agentique, et pour faire ce produit, on utilise BMAD, un système agentique. Oui ! Et pour améliorer ce système, j'utilise ce même système agentique. J'utilise BMAD pour améliorer BMAD".

Cette diffusion a toutefois ses angles morts. Les profils métiers non techniques (RH, finance…) restent encore à l'écart, et le gouffre persiste entre des experts qui s'envolent et des directions qui débutent ou, parfois, hésitent encore à se lancer.

Mais le changement le plus important n'est pas là

Le point de blocage culturel et historique de l'ingénierie logicielle (i.e. la vitesse de production du code) a littéralement sauté. Et c'est précisément parce qu'il a sauté qu'il faut regarder ailleurs.

La vélocité de production de features à tester (écriture de code et de validation par les tests) est devenue si rapide et massive qu'elle sature les autres rôles de l'organisation de questions, de besoins de validation, de besoins de spécification. Le goulet d'étranglement ne disparaît pas : il se déplace vers le Product Owner, les experts métiers, les directions non utilisatrices de l'IA, les utilisateurs finaux.

Illustration de la vitesse avec le témoignage d'une développeuse : "ça va très vite, l'IA écrit énormément de code [...] Tu suis un cheval au galop." Et l'avertissement d'un Tech Lead senior, qui tient en une phrase ce que la suite de cet article essaie de déplier : "les utilisateurs ne pourront pas absorber des nouveautés qui arrivent tous les jours".

Ce déplacement crée quatre tensions

1. L'asymétrie de rythme

Une Product Owner qui travaille avec une équipe de onze développeurs utilisant l'IA vit ce déphasage au quotidien et raconte la pression exercée sur son rôle : "Alimenter onze développeurs augmentés en tant que PO, faut suivre (rires) [...] L'équipe me plie des tickets à 13 points en 2h. On cherche une deuxième personne. Ça fait 2 jours que je suis off, le backlog est vide."

Un autre développeur explique que la fluidification et la vitesse du delivery grâce à l'IA exigent en contrepartie une présence et un "jus de cerveau" constants de la part du métier, ce qui change profondément la donne : "le code devient une commodité [...], la vérité du produit réside plutôt dans les spécifications. Et quand un service, une équipe, une direction prend une équipe augmentée pour travailler sur un sujet, elle a intérêt à être disponible, à avoir du temps de cerveau disponible et un jus de cervelle de qualité. Le processus est très engageant parce que, de facto, la valeur va venir de leur implication dans le projet."

2. La surcharge cognitive

Lorsque j'ai demandé explicitement à cette personne si la disponibilité devait être immédiate, plus réactive qu'avant, elle a sonné très vite l'alarme et mis en garde contre le piège du rythme de la machine qui ne s'arrête jamais : "C'est le piège de cette magie agentique, la charge cognitive qu'elle engendre. Parce que tu traites beaucoup plus de sujets dans une journée, tu vas beaucoup plus vite, tu as beaucoup d'outputs à scanner, à revoir, à corriger, à affiner, soit en dialoguant avec tes agents, soit en dialoguant avec des vraies personnes, avec tes vrais stakeholders. Et, on avait des sujets de frustration parce qu'on n'arrivait pas à avoir le même niveau d'implication."

Les LLM, les agents, l'IA ne fatiguent jamais. L'humain, lui, subit une sollicitation cognitive induite par une machine qui "tape sur l'épaule toutes les 20 minutes" (ou moins).

Attention toutefois à ne pas transformer ce constat en verdict. Ce que j'ai entendu, ce sont des vécus très contrastés. Certaines personnes décrivent une émulation collective intense, stimulante, qui tire les standards de qualité vers le haut. D'autres parlent d'un deep focus permanent qu'il faut tenir pour rester dans le flow, et de la nécessité de s'imposer des pauses. D'autres enfin se disent "rincés, épuisés". Le même outil, selon le contexte d'équipe, la maturité de l'organisation et le tempérament de la personne, produit de l'énergie ou en consomme. C'est précisément ce qui rend le sujet managérial : il ne se traite pas par une règle générale.

3. La fragmentation du collectif

L'IA insuffle une dynamique de travail renouvelée, plus directe et d'une précision chirurgicale. Pour un des tech leads interviewés, la convergence entre la technique et le produit devient le moteur indispensable de l'efficacité moderne : "L'IA rapproche le besoin métier de l'implémentation. Le couple PM/Architecte doit se comprendre parfaitement, sinon rien ne sort". Un "Product developer" (comme il aime à s'appeler) prédit : "les métiers vont se fondre. [...] Il y aura un Product developer qui aura plus une sensibilité Product, un autre peut-être avec une sensibilité plus tech [...] Mais à la fin, tout le monde est Product developer [...] les questions seront beaucoup plus précises."

Je constate, de mon côté, que les équipes de 2, 3 ou 4 personnes sont une organisation qui émerge de plus en plus fréquemment.

Cependant, cette intensification de l'échange au sein de binômes ou trinômes hyper-performants s'accompagne d'impacts organisationnels majeurs : l'éclatement des collectifs plus larges, et, parfois, la perte de l'échange de pair à pair. Les personnes peuvent se retrouver enfermées dans une relation exclusive avec l'outil. Un Product Designer exprime une vive inquiétude face à cette bulle cognitive : "les IA ont un impact social, sociétal, qui va complètement défavoriser l'échange, l'échange avec des pairs. Avant, tu te tournais vers quelqu'un, tu disais « qu'est-ce que t'en penses ? », la question hyper ouverte, et aujourd'hui, tu dis ça à ta machine. [...] tu ne demandes plus à ton copain, tu demandes à ton IA."

Face à ce risque d'isolement, de déconnexion, un commercial rappelle la nécessité absolue pour les managers et les organisations de réinvestir les espaces de socialisation hors machine : "il faut surtout et à tout prix qu'on maintienne les relations humaines. [...] les compétences sociales. Donc, faire peut-être plus de présentiel, plus de moments de convivialité... Pour que du coup les gens ne se détachent pas complètement de l'entreprise".

4. La responsabilité diluée

C'est la tension dont on parle le moins, et c'est probablement la plus structurante.

Ce qui frappe, au fil des interviews, c'est que chacune et chacun se construit son propre cadre de travail avec l'IA. Et ces cadres sont souvent sérieux : exigences de tests, relectures ciblées, étapes de vérification, critères personnels pour décider de ce qui part et de ce qui repasse par une paire d'yeux. La rigueur n'est pas le problème. Ce qui manque, c'est que ces cadres restent privés. Rien ne garantit que la personne d'à côté ait posé les mêmes, ni qu'elle le dise. Un Tech Lead met le doigt dessus : "On utilise l'IA à titre individuel et pas comme outil collectif [...] Ça m'énerve de relire du code (ndlr. généré par IA) si la personne n'a pas relu. Ça renvoie à la question de la transparence, de la responsabilité".

Sans contrat partagé, chaque relecture devient une loterie : on ne sait pas ce qui a déjà été vérifié, par qui, ni selon quels critères. L'effort de vérification se duplique ou disparaît, et dans les deux cas la confiance interne s'use.

Le sujet dépasse largement le code. Quand une spécification, une maquette, une synthèse d'entretiens ou une roadmap sont produites avec un agent, qui en répond ? Tant que la réponse reste floue, l'organisation accumule une dette d'un genre nouveau : du contenu que tout le monde a vu passer et que personne n'a vraiment endossé. C'est, à mon sens, le vrai angle mort de cette période — et c'est là que se joue la différence entre une équipe/organisation qui accélère sur le long terme et une équipe/organisation qui accélère quelques temps et dérape.

Les nouveaux gestes de management

Introduire l'IA dans une équipe IT (c'est souvent la porte d'entrée) n'est pas sans impact sur les membres de l'équipe, sur l'équipe elle-même (son organisation, ses rituels, son apprentissage, ses livrables) et également sur les personnes, les équipes qui sont amenées à travailler avec cette équipe IT.

La réponse à la question "est-ce que l'on va réussir à travailler efficacement de manière collective en présence des IA ?" est probablement ; personne ne peut affirmer, aujourd'hui, avec certitude que cela sera un succès collectif.

Ce "probablement" nous oblige à expérimenter : dans les gestes techniques, dans les interactions entre les métiers, dans la construction de nouvelles exigences… L'observation résultat de ces expérimentations permettra de faire le suivi : certaines seront abandonnées, d'autres seront conservées et améliorées, d'autres donneront de nouvelles idées. Les expérimentations réussies feront évoluer des pratiques émergentes vers des "bonnes pratiques" pour l'équipe et/ou l'organisation. En continuant ce cheminement de réflexion, d'essai, d'erreur, d'utilisation, certaines deviendront des "best practices", voire des standards de l'équipe ou de l'organisation.

Quelques pistes pour éviter de frustrer les différentes équipes ou de griller le cerveau des personnes ("brain fry") :

• Adapter la structure autour d'une équipe de développement qui utilise l'IA : par structure, je veux dire adapter les rôles, leur disponibilité et leurs tâches, adapter les rituels, ça peut être en fréquence, en contenu, en durée, la liste d'invités… L'usage de l'IA n'est pas un acte isolé à l'échelle des équipes de développement. Il convient d'établir des pratiques collectives, des règles de gouvernance d'équipe afin que la responsabilité partagée reste la norme.
• Rendre la responsabilité explicite et traçable. C'est le corollaire direct du point précédent, et il mérite d'être posé pour lui-même. Qui relit quoi, à quel moment, et qu'est-ce que "relire" signifie dans l'équipe ? Ce que l'on assume de livrer sans relecture humaine et ce que l'on n'assume pas ? Comment signale-t-on qu'un contenu a été généré ? Ces règles ne sont pas des formalités administratives : ce sont elles qui permettent à une équipe d'aller vite sans que la confiance interne ne se délite. Le sujet vaut pour le code comme pour les specs, les maquettes ou les synthèses.
• Vouloir aller plus vite suppose de poser des garde-fous : des glissières de sécurité le long de l'autoroute, des pneus autour d'un circuit automobile, des sorties alternatives en sable quand les freins lâchent en montagne. Côté code, les équipes peuvent poser des tests en tous types (unitaires, fonctionnels, bout en bout, de charge, de performance…). Je me pose des questions pour le côté produit et le côté organisationnel. À chaud, je dirai que plus que jamais les intentions et les objectifs doivent être très explicites et partagés. Le risque, c'est de poser un truc flou et d'alimenter l'IA avec ce flou. L'IA nous oblige à mieux penser notre ambition, notre cible et nos workflows dès le départ pour éviter des dettes (techniques / fonctionnelles / d'adoption).
• Vouloir aller plus vite suppose de sanctuariser des rituels de co-construction pour contrer l'effet de "bulle cognitive" et préserver l'échange entre pairs, déjà mis à mal après le Covid et l'explosion du télétravail. Formaliser des sessions régulières de relecture collective des besoins, des spécifications, du code, des fonctionnalités livrées. Formaliser des sessions de recueil de retours utilisateurs.
• Sensibiliser aux renouveaux des rythmes et, par exemple, aménager des "tempos humains" de maturation fonctionnelle pour ne pas épuiser le Product Owner et/ou saturer le métier sous un flux ininterrompu de tickets, de questions. Autre idée : s'imposer des temps collectifs artificiels de pause, des respirations d'équipe, permettra aux utilisateurs finaux d'assimiler les nouveautés et de garantir que le contenu produit (vision, roadmap, user stories) est le fruit d'une réflexion approfondie et non d'un automatisme sans valeur réelle. Un point de vigilance : ces respirations ne tiennent que si elles sont posées et assumées par la direction. Un temps convivial que l'on s'accorde en douce ne survit pas à la première deadline — et il fait même culpabiliser celles et ceux qui le prennent. Il faut que ce soit dit, arbitré et visible en haut.
• Épauler le métier par un coaching dédié pour gérer le déplacement du goulet d'étranglement vers les directions utilisatrices et métiers, pour gérer ce nouveau rythme de sollicitation. Ce coaching a pour rôle de structurer et réguler la densité des ateliers pour apporter des feedbacks de qualité, réguliers, à une échelle de temps gérable par l'humain.
• Repenser l'apprentissage et la formation des profils juniors : l'automatisation des tâches ne doit pas supprimer la formation des moins expérimentés. Les organisations doivent concevoir de nouvelles méthodes d'apprentissage axées sur l'esprit critique, l'audit de code, l'art de formuler l'intention.

Et moi, qu'est-ce que j'en fais ?

Ces interviews ne sont pas un exercice d'observation gratuit : elles déplacent aussi mon propre métier de coach orga.

Trois choses que je suis en train d’adapter dans ma pratique.

• Quand une équipe augmentée démarre, je regarde d'abord qui va devoir l'alimenter et lui répondre — par exemple, le PO, le métier, la direction — et si ces personnes ont la disponibilité et le cadre pour tenir la cadence. Le diagnostic se fait en périphérie, pas au centre. Et peut-être que “tenir la cadence” n’est pas l’objectif.
• Ensuite, je pose la question de la responsabilité beaucoup plus tôt qu'avant, et pas seulement avec les tech leads. "Qu'est-ce que vous assumez de livrer sans relecture humaine ?" est devenue une question d'atelier, de machine à café. Elle met souvent en lumière des désaccords que l'équipe n'avait pas explicitement formulés.
• Enfin, il n’y a pas de framework pour cette transformation. Du moins, pas encore. C'est peut-être moins rassurant pour certain·es qu'un modèle bien ficelé, mais c'est, pour l’instant, le seul rythme compatible avec celui du terrain. Ce que j'installe aujourd'hui, c'est un dispositif d'expérimentation : une pratique, une durée, un critère d'observation, un point d'étape. On garde, on ajuste ou on jette. J’utilise des connaissances en agilité, en Produit, en systémie, … des connaissances acquises auparavant lors de transformation d’une autre “génération”. Certaines sont pertinentes, des connaissances émergentes les complètent. J’apprends en marchant, au rythme des équipes/organisations que j’accompagne.

Je compte refaire ce tour d'interviews dans un futur sans doute proche. À la vitesse où le paysage bouge, la prochaine photo ne ressemblera probablement pas à celle-ci.

Pour finir : accélérer n'est pas avancer

Que se passe-t-il quand chaque maillon d'un système peut accélérer indépendamment des autres ? Rien de très nouveau, en réalité : on redécouvre qu'optimiser un maillon n'optimise pas la chaîne. Ce que l'IA fait de spectaculaire, c'est de rendre ce vieux principe brutalement visible, en quelques semaines au lieu de quelques années.

Il y a une deuxième question, plus inconfortable. Produire du code, produire des features et livrer de la valeur ne sont pas la même chose. Nous le savions déjà, mais tant que produire coûtait cher, le coût lui-même faisait office de filtre. Ce filtre a sauté. À quel moment considère-t-on que produire davantage n'apporte plus de valeur ? La question se pose aussi financièrement, d'ailleurs : les Octos découvrent le coût réel de la consommation de tokens en usage intensif et la fin du low-cost. Couplée à la dépendance exclusive vis-à-vis d'infrastructures étrangères — une sorte de bis repetita de la migration vers les clouds d'Amazon ou de Google —, cette réalité pousse certaines organisations à chercher des alternatives locales. Un Data lead évoque ce virage vers l'autonomie stratégique observé chez certains de ses grands clients, notamment bancaires : "Une banque a décidé d'être dans le souverain, l'autonomie stratégique. Donc tout est on-premise et ça n'utilise pas les clouds américains, …". Après l'euphorie, une forme de sobriété s'installe.

Les pratiques décrites dans cet article sont encore émergentes et ne représentent qu’une photo parcellaire du paysage du développement en 2026. Certaines pratiques disparaîtront, d'autres deviendront banales, et de nouvelles apparaîtront dans quelques mois. Une chose me semble néanmoins déjà acquise : introduire l'IA dans le travail ne consiste pas à ajouter un outil de plus. Dès qu'elle change la vitesse, le volume ou la nature de ce qui est produit, elle finit par questionner les rôles, les interactions, la structure même des équipes et parfois celle de l’organisation.

Nous sommes au début de ces transformations. Plutôt que de chercher trop vite les "bonnes pratiques", la question est peut-être aujourd'hui de savoir quelles expérimentations mener collectivement pour construire des organisations qui profitent de la puissance de l'IA sans se mettre elles-mêmes à son rythme.

Si vous menez déjà ces expérimentations de votre côté, j'aimerais beaucoup en entendre parler. C'est comme ça que la prochaine photo se construira.

Merci à Gabrielle Le Bihan, Cédric Chevalérias, Laura Krispin, Marina Wieser et Irénée Regnauld pour leur temps et leurs retours pertinents et précis.