IA : comment passer de gains individuels à une équipe plus performante

L'adoption n'est plus la question. Selon le rapport DORA 2025 de Google, 90 % des professionnels interrogés utilisent l'IA au travail et plus de 80 % estiment qu'elle a augmenté leur productivité. Pourtant, ce gain se retrouve rarement dans les indicateurs de livraison : la productivité ressentie se mesure au poste de travail, la performance sur la chaîne entière.

Les directions techniques avec qui nous avons échangé le formulent sans détour. Dans une grande organisation, l'adoption est souvent large mais hétérogène : certains développeurs pratiquent déjà des usages agentiques, d'autres en restent à l'autocomplétion, et les niveaux de maturité varient fortement d'une équipe à l'autre. Le constat partagé : un développeur équipé devient plus autonome sans entraîner ses collègues, et son gain se transforme en attente en amont ou en aval.

Les études publiques vont dans le même sens. Bain rappelle que l'écriture et le test du code ne représentent qu'environ 25 à 35 % du temps entre l'idée et le lancement d'un produit : accélérer cette seule portion a un effet mécaniquement limité. Les assistants de code apportent 10 à 15 %, souvent sans que le temps libéré soit réaffecté ; les gains de 25 à 30 % supposent une refonte des processus de bout en bout.

Le gain individuel ne disparaît pas : il change de place. En amont, le développeur attend une spécification, un arbitrage produit ou une maquette qu'il aurait autrefois eu le temps de voir arriver. En aval, ses demandes de fusion s'accumulent dans la file de revue, les tests de bout en bout tournent plus souvent et l'équipe d'exploitation absorbe davantage de changements. DORA 2025 note que l'adoption de l'IA est désormais associée à un meilleur débit de livraison, mais toujours à une stabilité moindre : l'accélération expose les faiblesses situées plus loin dans la chaîne.

Ces dirigeants en tirent une condition de réussite : le facteur limitant se déplace du nombre de développeurs vers le produit, la conception et l'architecture. Sinon, l'équipe produit plus vite ce qu'elle n'a pas eu le temps de bien définir.

Une scale-up avec qui nous avons échangé a remplacé un cycle de cadrage long, où le développeur intervenait après la définition de la solution, par de petites équipes constituées autour d'une mission, avec un objectif mesurable et une échéance. À l'échéance, l'équipe est prolongée ou dissoute. Le développeur y discute directement avec le métier, signale les cas limites et contribue à la conception. L'effet rapporté : une fonctionnalité qui mobilisait 3 ou 4 développeurs peut être réalisée par 1 ou 2, et c'est le produit qui devient le point de tension.

Dans une grande organisation, de petites équipes peuvent coexister avec des équipes classiques plus larges, sans qu'un avant et un après soit démontré : les produits historiques, les domaines spécialisés et le volume de code existant compliquent toute réorganisation. La piste évoquée est de tester ce format sur un périmètre neuf, sans exposer les produits historiques, et de connaître la maturité de chaque équipe avant d'arbitrer leur composition.

Les deux directions techniques partagent une difficulté : les pratiques évoluent plus vite que les cycles de conception des formations. Un parcours centralisé risque d'être obsolète avant d'être finalisé. Elles misent donc sur des dispositifs de diffusion entre pairs, chacun avec ses limites.

Une bibliothèque partagée répond à un besoin exprimé par les deux directions techniques : faire circuler entre équipes les agents et les instructions qui fonctionnent, plutôt que de laisser chacun reconstruire les siens. Un point commun se dégage : la pratique se diffuse surtout lorsqu'elle est rendue réutilisable, l'expliquer ne suffit pas.

Le rythme est le sujet le moins documenté, et celui que les dirigeants ont abordé avec le plus de prudence. Plusieurs sources de fatigue ont été citées : traiter plusieurs tickets en parallèle, suivre la vitesse des agents, concevoir et prototyper en boucle courte avec le produit, reprendre le contexte à chaque nouvelle revue. Reste à savoir s'il s'agit d'une difficulté d'apprentissage passagère ou d'un rythme durablement difficile à soutenir.

• Certaines équipes envisagent de séparer les temps de travail, avec la préparation des tâches l'après-midi, leur exécution par les agents la nuit et l'examen des résultats le matin.
• Certains développeurs le font déjà seuls : ils lancent des travaux le soir et les examinent le lendemain.
• Traiter la fatigue rapportée comme un problème d'organisation du travail, et non comme une difficulté individuelle.

DORA 2025 associe les équipes en « mode survie » à un épuisement élevé. Ajouter de la vitesse à une équipe sous tension ne la rend pas plus performante : la charge cognitive de la revue et des changements de contexte se pense au même titre que le débit.

Selon LeadDev et DX, qui ont interrogé plus de 880 responsables engineering en 2025, seules 18 % des organisations mesurent l'impact des outils IA sur leurs équipes de développement. Bain observe que les organisations les plus avancées mesurent le temps économisé et le réaffectent explicitement à un travail à plus forte valeur, pour que les gains d'efficacité deviennent des gains business.

• Le délai de bout en bout, de l'idée à la mise en production, plutôt que la vitesse d'écriture du code.
• Le temps passé en attente de revue et la taille des demandes de fusion.
• La stabilité : taux d'échec des changements et temps de rétablissement après incident.
• La maturité d'usage par équipe, pour repérer les écarts qui créent des attentes.
• La part du temps libéré effectivement réaffectée, et à quoi.

La maille de mesure compte autant que les indicateurs. Les dirigeants avec qui nous avons échangé recommandent de traiter l'équipe, et non le développeur, comme l'unité d'adoption : c'est la seule façon d'éviter qu'un gain isolé se transforme en attente ailleurs.

Si le code n'est plus le goulot d'étranglement, les compétences rares se déplacent. Nos échanges font ressortir deux trajectoires d'expertise pour les développeurs : le product engineer, proche du métier et de la conception, et le spécialiste des outils IA, des modèles, des skills et de l'architecture. Autour d'eux, quatre rôles prennent du poids : le tech lead, qui fixe les décisions que les agents doivent respecter ; l'engineering manager, qui organise l'équipe autour du flux plutôt que de la charge ; le product manager, qui doit alimenter une équipe plus rapide ; le coach agile, qui aide à redessiner les rituels et le rythme.

Ces profils ne se repèrent pas sur un critère de stack, et c'est précisément là que les canaux de sourcing habituels cessent de trier utilement. En entretien, nous regardons comment le candidat a fait évoluer la pratique de son équipe, et pas seulement la sienne : ce qu'il a documenté, partagé, mesuré, et ce qu'il a changé dans la revue ou la conception.