Transformation du processus de livraison

Depuis janvier, FurtherAI a réorganisé chaque étape du cycle de vie logiciel. En mars, les agents d’IA ont commencé à écrire le code, atteignant près de 100 % des changements. En avril, les tests générés par les agents sont passés de 15 % à 91 % des changements. Le mois de mai a vu l’IA réviser 99 % des pull‑requests, contre 60 % auparavant, laissant les humains se concentrer sur les cas nécessitant un jugement. En juin, les tests ont été parallélisés et filtrés pour ne garder que ceux impactés, ce qui a permis d’exécuter 20 fois plus de tests en 17 minutes. En juillet, ClaudeTag a automatisé l’ingestion des bugs, créant 60 % des tickets sans intervention humaine. En août, 21 règles Python ont été introduites pour transformer la connaissance tribale en contrôles automatisés, rendant possible la fusion autonome d’un tiers des changements à faible risque. Enfin, en septembre, les canaux Slack permettent à plusieurs utilisateurs de piloter un même agent pour ouvrir des pull‑requests, illustrant la collaboration en temps réel.

Impact sur la productivité et les métriques

Le nombre de modifications de code fusionnées par ingénieur a augmenté d’un facteur 5 depuis le début de l’année, tandis que le taux de revert est resté inférieur à 0,5 %. Le volume de changements par ingénieur est passé de 17‑30 par mois (juillet‑août) à 45 en septembre, et 48 en octobre, montrant une montée en cadence soutenue. Malgré cette accélération, le temps consacré aux tests et à la mise en place d’outils a absorbé une part importante des ressources, ce qui explique pourquoi le nombre de changements client‑facing par ingénieur n’a pas suivi la même progression.

Évolution des rôles et des responsabilités

Le gain de vitesse dans l’écriture du code a déplacé le goulot d’étranglement vers la phase de planification et de revue, qui représente désormais 70 % du temps total d’une fonctionnalité contre 40 % auparavant. Pour contrer ce phénomène, FurtherAI redéfinit les niveaux de seniorité : les ingénieurs juniors utilisent les agents et détectent les erreurs, les seniors planifient et révisent leurs propres travaux, et les staff engineers prennent en charge des problèmes vagues, évaluent les compromis et mesurent les résultats. Les managers, quant à eux, sont invités à « être dans le travail », à tester les fonctionnalités en staging comme des utilisateurs finaux et à développer une expertise produit afin de guider les décisions sans créer de couches de gestion supplémentaires.

Enjeux et limites

Si l’automatisation a permis de réduire les frictions techniques, la capacité à décider « quoi construire » devient le facteur limitant. Les équipes doivent désormais investir dans la formation des ingénieurs à la prise de décision produit et dans des outils de priorisation qui restent compatibles avec le rythme accéléré de livraison. De plus, la dépendance à des agents propriétaires (ClaudeTag, Poirot, Sherlock) introduit un risque de verrouillage technologique et nécessite une surveillance continue pour éviter les dérives de qualité. Enfin, l’implication de non‑ingénieurs dans le code, bien que bénéfique pour la rapidité, soulève des questions de gouvernance et de conformité qui devront être encadrées par des politiques claires.