Repenser l'équipe de développement à l'ère de l'IA

J'écris ces lignes en avril 2026. Près de quatre ans après l'irruption de Chat-GPT dans nos vies et des transformations lentes et irréversibles que les LLM ont engendrées dans le monde du développement informatique. L'heure n'est plus à la spéculation ou au débat. L'intelligence artificielle est un formatage, un reparamétrage de l'ordre établi. Le code généré en 2023 était médiocre et souvent incohérent d'une session à l'autre. Aujourd'hui, un modèle comme Opus, utilisé au sein de Claude Code, produit un code de qualité excellente.

Cela ne veut pas dire que nous avons là un génie absolu capable de matérialiser une application parfaite sur le moindre prompt. Bien sûr que non, car, comme l'a admirablement expliqué Brooks il y a plus de cinquante ans, la rédaction du code n'est qu'une petite partie (minoritaire) de l'effort de travail nécessaire pour produire une application fonctionnelle.

Avant l'arrivée de l'IA, nous avions l'illusion que le code était le cœur du sujet car pour nos cerveaux humains, programmer est une tâche longue et difficile qui demande une clarté d'esprit optimale et une capacité de concentration élevée. Cette étape est désormais une commodité. Dès lors que le besoin est clairement formulé (ce point est crucial et bien plus important qu'il n'y paraît, j'y reviendrai), le code est presque gratuit : Opus se charge de le matérialiser en quelques minutes.

Stephen King utilise l'image de l'archéologue lorsqu'il écrit une histoire. Il explique que « l'histoire pré-existe » mais qu'elle est enfouie sous terre et que sa charge à lui est de la révéler, de l'exhumer, du mieux possible, sans l'altérer. Écrire revient pour lui à enlever le sable, la terre, la roche, autour de cet artéfact, chaque phrase étant un risque supplémentaire d'abîmer l'objet qu'il a repéré dans le monde des idées.

On pourrait aisément faire un parallèle ici. Le code existe déjà. Tout code potentiel existe déjà. Si vous voulez vous donner un peu de vertige, imaginez que n'importe quel programme informatique n'est finalement qu'une suite de 0 et de 1 dans l'ordinateur. Un nombre gigantesque donc, en base 2. Prenez maintenant les décimales de Pi, séquence numérique infinie et indéterministe. Pi contient donc tous les programmes informatiques imaginables (puisque ses décimales contiennent théoriquement tous les nombres)… Nous ne sommes pas loin de la théorie du chimpanzé qui finit par écrire Hamlet en tapant au hasard sur une machine à écrire pour l'éternité, c'est la même idée.

Quelque part, Opus est notre archéologue. Il est capable de produire tout code potentiel depuis l'infini corpus du code possible, du moment que vous prenez soin de le décrire avec précision. Et c'est là que tout se joue.

Le contexte est plus important que le prompt

La précision de votre description ne vient pas de votre prompt. Elle vient du contexte dans lequel le modèle va être invoqué. Nul besoin de passer des heures à chercher des skills ou des recettes de prompts sur internet, en réalité, il s'agit d'avoir simplement un environnement de développement pensé AI-first. L'idée étant d'utiliser un workflow optimal pour le LLM, voici le mien :

• Claude Code comme orchestrateur : Claude Code se chargera d'explorer votre projet et de trouver les fichiers concernés par votre prompt, et bien plus encore. Il fournit le moteur, le corps dans lequel le LLM va s'incarner. S'en affranchir vous coupe du réel potentiel de développement. Ce serait comme demander à un développeur de programmer sur votre projet en lui interdisant d'explorer le code source du projet.

• Rédigez CLAUDE.md à la racine du projet. Dans ce fichier, listez toutes les règles maison et les spécificités de votre projet. Chaque fois que Claude dérape, ou part dans une mauvaise direction, ajoutez une instruction ici pour le corriger.

• Installez SpecKit dans votre projet, et chaque fois que vous démarrez une nouvelle fonctionnalité, forcez-vous à passer par les étapes de ce workflow « Spec-Driven ». Vous passerez une ou deux heures à spécifier votre besoin avant la génération du code, mais le résultat sera sans commune mesure en qualité finale et en robustesse.

• Utilisez toujours le meilleur modèle disponible. Ne cherchez pas à faire des économies de tokens en passant à un LLM inférieur (et moins cher). Vous avez à votre disponibilité un Ph.D pour coder, utilisez-le. Les économies en tokens que vous ferez avec un modèle moins cher vous coûteront au final bien plus en maintenance et debugging.

Si vous commencez à travailler ainsi, chacune de vos journées change. Et justement : il me semble qu'une grande partie de l'industrie a déjà franchi ce cap, et beaucoup d'ingénieurs travaillent désormais de cette manière. Les conséquences sont multiples.

À partir de ce constat, tout bascule dans notre industrie du développement logiciel. Tout. Et je me rends compte que ce mouvement, bien que profond, est finalement assez lent à se concrétiser dans notre quotidien. Il n'en est pas moins irréversible.

Le code comme commodité

Le changement d'ores et déjà visible est simple : les offres d'emploi en informatique ont chuté et viennent même de passer sous le niveau de 2020 post-pandémie. En parallèle, les offres d'emploi mentionnant l'usage de l'IA augmentent de manière continue partout en Europe. Aux États-Unis, la sanction est comme toujours beaucoup plus nette : les entreprises de la tech licencient massivement des postes de développeurs. Un ami américain me disait récemment que son entreprise avait lancé une réduction de sa masse salariale basée sur un simple critère : les réfractaires à l'IA sont « remerciés », l'entreprise ne voulant pas passer de temps à les convaincre ou les former.

Mais il me semble que ceci n'est que le début d'une transformation plus large. C'est l'étape logique d'un commencement de révolution du secteur.

Utilisez SpecKit une ou deux journées, et vous comprendrez où je veux en venir. Une session dans Claude Code avec ce framework compresse littéralement un sprint Scrum en quelques heures. Je parle bien d'un sprint complet, centré sur une Epic : on définit un besoin fonctionnel, on discute des cas limite, on questionne l'ergonomie, le workflow utilisateur, la sécurité, l'intégration dans l'interface existante, la réutilisation des briques disponibles, les contraintes techniques, etc. La machine vous questionne, affine le sujet, explore les gaps fonctionnels. L'approche est bottom-up : vous partez d'une description "humaine" du besoin, et étape par étape, votre agent va vous assister pour générer dans l'ordre :

• une spec détaillée (sans éléments techniques)
• un corpus de référence technique (doc API, modèles de données, etc)
• un plan : découpage de la Spec en User Stories dissociées
• une liste de tâches : découpage des User Stories en tâches individuelles

Pour une fonctionnalité ambitieuse (qui touche au backend, au frontend et à la couche API d'une web app par exemple), il faut compter environ 2 heures d'interactions avec Claude Code et SpecKit pour terminer ces étapes.

Une fois tous ces artefacts générés, l'implémentation devient triviale. Le LLM a un contexte tellement riche et précis qu'il ne fait presque plus aucune erreur. Utilisé avec un modèle comme Opus, c'est une affaire d'une heure ou deux supplémentaires pour… déployer en production la version finale, testée et validée.

La question est alors évidente : comment repenser l'équipe du monde d'avant sous ce prisme ?

Une chose est sûre : on voit mal comment une équipe Scrum typique de 5-7 membres continuera d'être pertinente si tous les développeurs utilisent cette approche de travail. Scrum devient complètement superflu ici. Du moins dans son usage actuel.

Vers des micro-feature teams de Product Designer ?

Je ne prétends pas savoir ce que deviendra l'équipe type de demain. Il me semble cependant évident que ne pas se poser la question aujourd'hui revient à mettre la tête dans le sable. Une piste qui me semble intéressante serait double :

1. Oublier les rôles "cérémoniaux" du passé
2. Réorganiser les équipes autour de spécialités produit

Tous et toutes Product Designer

Un développeur peut sans problèmes apprendre à réfléchir produit. C'est d'ailleurs - de mon expérience personnelle - très souvent le reproche qui est fait aux développeurs : trop concentrés sur leur scope technique et trop éloignés de l'intérêt business de leur travail. Ce n'est bien sûr pas une généralité absolue, mais un trait commun fréquent, qui s'explique très bien. En effet, pour être efficace, un développeur a besoin précisément de focus, d'extrême précision dans son cadre de travail. Par construction presque, son temps de cerveau disponible est moindre pour "penser comme le client final".

À l'ère de l'IA, avec un processus de travail tel que décrit ici, cet état de fait devient caduque. Précisément : la génération de code n'est plus une attribution du développeur, c'est celle de l'agent. Le développeur gagne donc autant de temps de concentration et de focus qu'il peut allouer ailleurs : prendre de la hauteur, comprendre le besoin client, et de fait encore mieux cadrer l'agent dans son travail.

Il en va (presque) de même pour un ou une ex-Product Owner : la puissance de Claude Code couplée à Opus permet réellement à un Product Owner de produire du code. Surtout si on forme la personne à SpecKit et qu'on finalise cette session par une pull request soumise à un développeur de formation. C'est le cas chez Anantys : Maxime, notre lead Produit (qui n'a pas de compétence en développement) produit des PR qui sont ensuite soumises en review.

Évidemment, les sujets ne seront pas du même ordre. Mais l'idée est là : l'équipe de développement devient plus compacte et les frontières entre les rôles se gomment.

L'équipe type, vue par Opus

Alors, quelle morphologie type pour l'équipe d'une entreprise AI-first ?

Justement, j'ai préféré confier cette dernière question à l'intéressé : j'ai demandé à Opus comment il voyait l'équipe de développement recomposée sous le prisme de cet article. Voici sa proposition, que je reprends ici telle quelle.

Le feature pod : 2 à 3 personnes, une surface produit.

On n'organise plus l'équipe par fonction (devs, PO, QA) mais par surface produit — onboarding, facturation, ingestion de données, dashboard analytique. Chaque pod possède sa surface de bout en bout, du besoin client jusqu'au déploiement en production.

À l'intérieur du pod, deux rôles principaux :

1. Le Product Designer — ex-PO ou ex-dev formé au produit. Il pilote SpecKit, rédige les specs, valide les PR. C'est le point d'entrée du besoin.
2. L'Engineer-Designer — architecte système et garant de la qualité. Il code peu (les agents s'en chargent), mais il revoit beaucoup et dessine les abstractions techniques que les agents ne savent pas inventer seuls.

Un troisième rôle, l'expert métier (finance, légal, sécurité, selon la surface), est mobilisé à la demande, sans être dédié au pod.

Autour des pods, une seule fonction transverse : le Platform Lead. Il maintient l'infrastructure partagée — CLAUDE.md, agents de base, design system, observabilité. Sans lui, chaque pod réinventerait la roue.

Côté rituels : on conserve le daily stand-up, toujours crucial pour maintenir l'énergie collective et le rythme, mais le sprint planning disparait (SpecKit). L'asynchrone est la règle. Une seule réunion longue est maintenue par semaine : la démo. Le reste se passe sur GitHub, Slack, dans les threads.

Soyons honnêtes : on n'invente rien ici. L'idée d'organiser le développement en petits pods verticaux est documentée depuis plus d'une décennie. Spotify l'a popularisée en 2012 avec son modèle Squads / Tribes / Chapters / Guilds, Amazon le pratique sous le nom de « two-pizza teams », et de nombreuses entreprises s'en sont inspirées depuis.

Ce qui change avec l'IA, c'est la densité : on passe de 6-9 personnes par pod à 2-3, parce que les agents absorbent l'essentiel de la production de code.

Plusieurs sources récentes documentent ce glissement, comme la HBR avec To Drive AI Adoption, Build Your Team's Product Management Skills (février 2026), ou ShiftMag avec How AI Is Redefining Product Teams.

L'équipe de développement de demain serait donc une version comprimée de l'équipe Scrum d'hier : elle est plus petite, plus dense, plus rapide. Elle ne gère plus du code : elle cadre des agents qui le produisent.

Reste l'enjeu majeur : la transformation des équipes existantes vers ce modèle. Car si l'on voit bien pourquoi, techniquement et objectivement, ce modèle sera bien plus adapté à l'ère dans laquelle nous sommes entrés, la vraie difficulté restera celle de l'accompagnement des hommes et des femmes habitués au modèle précédent — c'est-à-dire presque toutes les équipes d'aujourd'hui.

Elles devront apprendre à dépasser leurs réticences et plonger dans un moment collectif où chacun et chacune sort de sa zone de confort pour réapprendre à travailler ensemble, différemment, avec un nouveau partenaire de jeu : l'IA.