Ciaran Cosgrave, PDG de Nearform, examine les avantages des équipes natives d'IA par rapport aux structures pyramidales traditionnelles en génie logiciel.
Deux ingénieurs. Six mois. Un produit valant un milliard de dollars. C'est ce qu'il a fallu à Anthropic pour faire passer Claude Code du concept à l'infrastructure à l'échelle de l'entreprise. Il ne s’agit pas d’un prototype ou d’un outil interne de niche, mais de quelque chose qui, début 2026, est devenu essentiel à la mission de l’ensemble de l’organisation.
Claude Code a été développé à l'aide d'agents d'IA pour accélérer les itérations, permettant un rythme de 60 à 100 versions internes par jour, chaque ingénieur allant bien au-delà de la production typique de l'industrie. En janvier 2026, presque tout le code d'Anthropic était écrit avec Claude Code lui-même. Désormais, il ne s'agit pas seulement d'un développement plus rapide, car Claude Code est devenu un modèle fondamental conçu pour permettre à de petites équipes de compresser ce qui prenait auparavant des années en quelques mois seulement.
Bienvenue dans l'équipe d'ingénierie native de l'IA. Cela ne ressemble en rien à ce que la plupart des organisations construisent.
L’autopsie du modèle de prestation traditionnel
Le modèle traditionnel d’équipe de conseil en technologie repose sur l’idée simple selon laquelle plus de personnes équivaut à plus de production, et les centres offshore ont permis d’augmenter la capacité rapidement et à moindre coût. Les équipes composées de jeunes ont généré des marges, tandis que les ingénieurs seniors ont assuré la supervision et la direction. Ce modèle d’équipe en forme de pyramide est devenu grand et fort.
Mais à mesure que ces grandes équipes distribuées se développaient, la complexité de leur coordination augmentait également. « Agile » est apparu comme une réponse à ces frictions et constitue une véritable amélioration par rapport à ce qui précédait. Les processus séquentiels en cascade hérités de l'industrie manufacturière et de la défense dans les années 1970 étaient catastrophiquement mal alignés avec les réalités du logiciel, et l'agilité est intervenue avec une réponse consistant à raccourcir les cycles, à adopter l'itération et à considérer les logiciels fonctionnels comme la principale mesure du progrès.
Mais même s’il a toujours sa place, l’agile est conçu pour un monde où les humains écrivent chaque ligne de code, où dans certaines situations il peut comporter des compromis quelque peu normalisés.
Le problème des commentaires sur les revues de sprint est le plus évident. Agile a promis des boucles de rétroaction étroites pour garantir que les équipes construisent la bonne chose, mais ce qui peut réellement arriver, c'est que les commentaires arrivent après deux semaines de construction. La démo révèle un désalignement. Corriger le cap à mi-sprint est politiquement difficile et la refonte lors du prochain sprint est démoralisante. Le cycle de deux semaines qui était initialement conçu comme une discipline est vite devenu un plafond.
Et derrière tout cela se cache un échec structurel que l’IA rend désormais impossible à ignorer : la plupart des implémentations agiles en entreprise ne sont pas toujours agiles. L’équipe itère à l’intérieur d’un conteneur en cascade. Cycles budgétaires, portes de gouvernance, contrats à portée fixe : l’organisation se comporte avec toute la rigidité d’une planification séquentielle tout en supportant les frais généraux des processus agiles. Il s'agit d'un mode d'échec coûteux, car il ne produit ni les avantages de l'agilité ni la prévisibilité de la cascade, mais simplement le coût des deux.
Et c’est là que le modèle commence à se briser. Le codage ne représente qu’une fraction de la fourniture de logiciels de bout en bout, mais les systèmes natifs d’IA réduisent radicalement le travail humain nécessaire à son exécution. L'exécution tactique, les tests, la documentation, le débogage et l'échafaudage sont de plus en plus automatisés (sans parler de la façon dont nous pouvons utiliser l'IA pour nous aider dans les exigences, le prototypage, etc.).
Lorsque 60 à 80 % des efforts d’ingénierie de routine peuvent être éliminés, l’échelle des effectifs cesse d’être un avantage. Le véritable goulot d’étranglement se déplace entièrement de la mécanique d’écriture du code vers l’architecture de la complexité du système et l’intention commerciale. Essentiellement, l’échelle cesse rapidement d’être un avantage et commence à ressembler à une inefficacité.
Les grandes équipes introduisent des frais généraux de coordination. La prise de décision ralentit. Le contexte est perdu à travers les couches. Ce qui était autrefois une force – l’effectif – devient un frein à la livraison. Votre pyramide ne s’effondrera pas du jour au lendemain, mais elle commencera à se creuser.
La ressource rare a changé
En 2025, les systèmes d’IA ont franchi une étape remarquable. SWE-bench Verified, une référence d'ingénierie pour les modèles d'IA, a vu les meilleurs scores passer d'environ 60 % en 2024 à près de 100 % en 2025. Dans des conditions contrôlées, les modèles d'IA peuvent désormais résoudre presque tous les problèmes d'ingénierie logicielle définis.
Selon une enquête menée auprès de plus de 24 000 développeurs dans le monde, 85 % d'entre eux utilisent désormais régulièrement des outils d'IA pour le codage et la conception de logiciels. GitHub Copilot a dépassé les 20 millions d'utilisateurs à la mi-2025, avec une augmentation de 75 % du nombre d'abonnés payants d'une année sur l'autre.
Lorsque la génération de code est abondante et bon marché, la rareté change. La nouvelle ressource rare est le jugement (et le budget limité pour les jetons). La capacité à traduire un problème commercial compliqué et controversé en une spécification technique précise qu’une IA peut exécuter de manière fiable devient bien plus vitale. L’intuition en matière de sécurité, la prévoyance architecturale et la capacité humaine à savoir ce qu’il ne faut pas construire sont autant de produits nouvellement demandés.
D’ici fin 2026, 75 % des développeurs orchestreront plutôt que coderont. Ce n’est pas une prévision lointaine. C'est déjà la réalité opérationnelle des équipes les plus performantes.
Les ingénieurs qui prospèrent dans cet environnement n’essaient pas de surpasser l’IA, mais ce sont eux qui comprennent que leur valeur principale est désormais de décider quoi construire, de réfléchir dès le départ aux objectifs et aux spécifications du code et de vérifier qu’il a été construit correctement – et non de produire eux-mêmes le code ligne par ligne.
À quoi ressemble vraiment l’IA native ?
Une équipe d’ingénierie native de l’IA reflète ce changement dans la façon dont elle est structurée et comment elle fonctionne, car elle suppose que l’IA gère l’exécution, tandis que les humains gèrent le jugement.
En pratique, cela conduit à des équipes plus petites et plus expérimentées. Alors qu'un modèle de prestation précédent pouvait nécessiter huit à 12 ingénieurs, avec une poignée d'ingénieurs juniors répartis partout, les équipes natives de l'IA tendent vers trois à cinq ingénieurs expérimentés complétés par des systèmes d'IA. La forme de l'équipe change parce que la nature du travail a changé.
Les rôles évoluent en conséquence. Les ingénieurs seniors passent moins de temps à rédiger des passe-partout et plus de temps à définir les contraintes du système, à prendre des décisions architecturales et à examiner les résultats générés par l'IA. L'assurance qualité passe de l'écriture manuelle de cas de test à la conception de stratégies prenant en compte les modèles de code générés par l'IA, et les chefs de produit réalisent de plus en plus de prototypes directement avec l'IA, réduisant ainsi l'écart entre la spécification et la mise en œuvre.
L’IA peut désormais générer une part importante du code de production, mais dans les équipes performantes, chaque ligne passe toujours par un examen humain. La compétence clé de l’ingénierie n’est plus la génération. C'est une validation : apprendre à connaître les processus de base qui utiliseront l'IA et s'assurer qu'elle résout réellement les problèmes et n'ajoute pas une couche de stress supplémentaire.
Même la façon dont les performances sont mesurées commence à changer. Les mesures traditionnelles telles que les tickets fermés ou les lignes de code écrites deviennent moins significatives lorsque le résultat peut être généré à grande échelle et que l'activité n'est plus un indicateur du mérite, et l'observabilité technique doit passer du suivi de l'activité des développeurs à la mesure du temps de cycle de la valeur commerciale ou de la stabilité du système.
Même des signaux plus récents, comme l’utilisation de jetons, peuvent devenir des pièges, récompensant le volume plutôt que la valeur et encourageant des comportements inefficaces et coûteux à grande échelle. La question cruciale devient : à quelle vitesse une équipe peut-elle vérifier que ce qui a été produit est réellement exact, éthique et précieux ?
Expédition du futur
Rien de tout cela ne suggère que les grandes équipes disparaîtront du jour au lendemain. Mais la structure des opportunités est en train de changer. Les rôles juniors évolueront vers une résolution de problèmes d'ordre supérieur et une collaboration en matière d'IA, et les ingénieurs seniors deviendront encore plus essentiels en tant qu'orchestrateurs de systèmes complexes entre l'homme et l'IA. Et les cabinets de conseil devront s’éloigner des modèles à forte intensité de main d’œuvre pour se tourner vers une prestation axée sur les résultats.
Les entreprises devraient se demander si elles ont repensé la façon dont elles fournissent leurs logiciels, ou si elles ont simplement rendu l'ancien modèle légèrement plus rapide, car « légèrement plus rapide » n'est pas la destination. Les équipes qui définiront la prochaine décennie de fourniture de logiciels construisent quelque chose de structurellement différent : plus petites, plus expérimentées, plus axées sur le jugement que sur l'exécution, fonctionnant avec des agents d'IA comme de véritables membres d'équipe plutôt que comme des accessoires de productivité. Et cela nécessite un examen attentif non seulement de la technologie et des outils utilisés, mais également des considérations humaines – comme la formation et la mise en place d’incitations – et de la conception des processus.
Le bi-ingénieur Claude Code n'est pas une anomalie à admirer de loin. C'est un modèle. Les organisations qui le traitent comme tel et le repensent en conséquence seront les garants de l’avenir. Ceux qui ne le feront pas se retrouveront dépassés par des équipes d’une fraction de leur taille, se demandant quand les choses auront changé.
Par Ciaran Cosgrave
Ciaran Cosgrave est le PDG de Nearform. Il travaille dans les domaines de la stratégie commerciale et informatique, de l'innovation et de la culture d'entreprise, se spécialisant dans le mobile, le cloud, la transformation commerciale, l'innovation et la stratégie.
