Chaque responsable d’ingénierie développant des infrastructures critiques a fonctionné selon une hypothèse fondamentale : vous pouvez avoir la rapidité ou la fiabilité, mais atteindre les deux simultanément était considéré comme impossible.
Ce n’est pas un problème de processus ou d’équipe. Pendant des années, l’industrie a accepté cela comme une limitation fondamentale de la façon dont les logiciels sont créés. La fiabilité nécessite des cycles de publication lents et méthodiques. Les tests exhaustifs prennent du temps. Les revues de code créent des goulots d’étranglement. Chaque couche de sécurité ajoute des semaines aux délais de livraison.
Dans les plateformes de recharge de véhicules électriques, les enjeux sont plus élevés que dans les logiciels classiques. Vous ne pouvez pas vous permettre d’indisponibilité, car chaque minute d’interruption signifie une perte de revenus. Mais vous ne pouvez pas non plus vous permettre une livraison lente de fonctionnalités, car les opérateurs de points de charge doivent s’adapter à l’évolution du marché.
Nous avons refusé d’accepter que « lent » soit le prix de « sûr ».
Nous avons reconnu que l’IA avait atteint un niveau de maturité où ce compromis pourrait enfin être résolu. La question n’était pas de savoir s’il fallait utiliser l’IA, mais comment architecturer un système d’ingénierie dans lequel rapidité et qualité se renforcent mutuellement plutôt que de s’opposer, un changement que nous décrivons dans Comment AMPECO est devenu natif IA.
Nous avons donc reconstruit l’ensemble du processus de développement logiciel d’AMPECO autour d’agents IA—non pas pour choisir un côté du compromis, mais pour le briser entièrement. Nous avons automatisé l’intégralité du cycle de développement : planification, codage, tests et déploiement, avec l’IA gérant l’exécution pendant que les ingénieurs dirigent l’architecture et valident la qualité. L’impact : des stories de 2 jours compressées en quelques heures, des taux de bugs réduits de moitié, et nous sommes passés de sprints hebdomadaires à des livraisons quotidiennes.
Voici comment nous l’avons fait.
Construire l’agent de développement CoOperator
Nous avons expérimenté des outils de codage IA pendant près de deux ans. GitHub Copilot pour l’autocomplétion. L’assistant de revue de code CodeRabbit. L’éditeur IA Windsurf. Tous montraient du potentiel mais offraient des résultats mitigés. Chaque outil nous apportait des améliorations progressives, mais rien qui changeait fondamentalement la donne.
La percée est venue avec Claude Code d’Anthropic. Les outils précédents nécessitaient une supervision constante—les développeurs devaient lire les résultats intermédiaires et taper « continuer » pour maintenir le processus en mouvement. Claude Code a changé cette dynamique : il pouvait travailler sur une tâche sans interruption, et lorsqu’il signalait l’achèvement, le travail était véritablement terminé. Fait crucial, il était également scriptable via un SDK, ce qui nous a permis de l’intégrer comme une étape fiable dans nos flux de travail automatisés.
Nous avons pris notre processus existant—un processus qui fonctionnait déjà bien—et l’avons décomposé en petites étapes individuelles. Cette approche granulaire était essentielle pour éviter de surcharger les limites de contexte des modèles d’IA actuels.
Pour chaque étape, nous avons rédigé des instructions spécifiques—du type que vous donneriez à un développeur humain—définissant exactement comment accomplir la tâche et à quoi ressemble « terminé ». Nous avons enregistré ces instructions sous forme de prompts exécutables.
Ensuite, nous avons organisé ces étapes en un flux de travail qui reflète exactement le processus suivi par notre équipe d’ingénierie humaine. Nous avons découvert qu’il n’y avait aucune étape fondamentale que l’IA ne pouvait pas faire—de l’écriture du code à l’assurance qualité—tant que la portée était gérée correctement.
Le résultat est ce que nous appelons l’agent de développement CoOperator (CODA). Il sert de gestionnaire de flux de travail qui orchestre l’exécution de ces instructions, pilotant effectivement le processus de bout en bout. Une phase d’architecture crée un plan détaillé, une phase de développement rédige les tests et implémente les fonctionnalités, et une phase de revue de code effectue une revue interne par les pairs, validant strictement le travail par rapport aux normes de codage, aux modèles architecturaux et aux exigences de la story. Lorsque des problèmes sont identifiés, le flux de travail revient en arrière pour les corrections, se répétant jusqu’à ce que le travail soit terminé.
Le moteur IA : Éliminer systématiquement les interruptions humaines
Nous avons réalisé que dans un système natif IA, la contrainte principale sur la rapidité n’est pas le temps de génération de l’IA—c’est le temps de cycle humain. Attendre qu’un humain examine un plan ou approuve une étape crée un « temps mort » qui détruit la vélocité.
Notre approche ne consiste pas à gérer des « boucles » d’interaction humain-IA. Il s’agit d’établir des points de contrôle, puis de les supprimer systématiquement à mesure que nous gagnons en confiance dans l’autonomie de l’agent.
De la supervision à l’autonomie
Initialement, notre processus était fortement encadré. Un Product Manager approuvait la story, puis les agents IA (Architecte et QA) généraient un plan technique. Un développeur humain devait s’arrêter, examiner et approuver ce plan avant que toute implémentation puisse commencer. Ce n’est qu’alors que les agents d’exécution (Développeur, Revue de code et Test d’acceptation) menaient la tâche à son terme, suivis d’encore une autre revue de code humaine.
À mesure que les agents ont prouvé leur capacité, nous avons identifié que le point de contrôle de « revue du plan » était un goulot d’étranglement. L’IA était capable de planification valide sans encadrement constant. Nous avons donc supprimé cette interruption humaine.
Le flux de travail actuel
Aujourd’hui, une fois que le Product Owner et l’ingénieur marquent une story comme « Prête pour le développement », les agents prennent entièrement le relais. Ils gèrent de manière autonome la planification architecturale, la planification des tests, l’implémentation et l’auto-correction. Le système itère en interne—écrivant du code, exécutant des tests, corrigeant des erreurs—jusqu’à atteindre un état « prêt pour la production ».
Le développeur humain n’intervient qu’à la toute fin pour une revue finale. À ce stade, il peut approuver le travail ou fournir des retours. Si l’agent se bloque ou a besoin d’un recadrage, le développeur peut mettre à jour manuellement les instructions de l’agent ou le contexte du projet et redémarrer l’ensemble du processus afin de s’assurer que la mise à jour résout le problème.
Le chemin vers le zéro contact
L’objectif est de continuer à supprimer ces points de contrôle humains. Nous prévoyons que dans les mois à venir, nous atteindrons un niveau de confiance où nous n’aurons plus besoin d’une revue de code humaine pour chaque tâche. En éliminant ces interruptions, nous permettons à l’IA de livrer à sa pleine vitesse théorique, transformant des jours de latence en minutes d’exécution.
Le filet de sécurité de plus de 25 000 tests
Pour permettre ce niveau d’automatisation par IA, vous devez d’abord mettre en place les filets de sécurité. Mais ce ne sont pas de nouveaux filets de sécurité que nous avons inventés pour l’IA.
Notre système repose entièrement sur la discipline des tests unitaires et fonctionnels obligatoires, de l’intégration continue et de la gouvernance de sécurité automatisée—des pratiques que nous avons maîtrisées il y a des années pour aider nos équipes humaines à avancer rapidement. Nous avons simplement découvert que ces mêmes pratiques aident nos agents IA tout autant qu’elles aident nos ingénieurs humains.
Pour nous, cette fondation est une suite massive de plus de 25 000 tests automatisés. Un agent ne peut tout simplement pas définir une tâche comme « terminée » tant qu’il ne produit pas les tests qui prouvent que le code fonctionne. Cela donne à l’IA un retour immédiat et programmatique. Elle n’a pas besoin de « deviner » si la logique est correcte ; la suite de tests le lui indique instantanément. Si un test échoue, l’agent se corrige automatiquement et réessaie jusqu’à ce que la logique soit valide.
Cette densité de tests—générés à une vitesse que les humains ne pourraient égaler—est ce qui nous permet de déployer quotidiennement sans chaos. Elle détecte les régressions instantanément et garantit que les nouvelles fonctionnalités ne cassent pas les fonctionnalités existantes. Sans ce cadre rigide, un agent IA produirait simplement du code bogué plus vite que les humains ne pourraient le corriger.
Bien que les tests soient le garde-fou principal, nous les renforçons avec d’autres outils automatisés d’analyse statique de code. Tout comme ces outils empêchaient les humains de fusionner du code désordonné ou non sécurisé, ils bloquent maintenant les agents IA. Si l’IA génère du code qui fonctionne correctement mais viole les normes architecturales, ces outils arrêtent le processus.
En fin de compte, nous n’avons pas construit l’IA sur des promesses vides ; nous l’avons construite sur une discipline d’ingénierie établie.
Points de contrôle humains maintenus
Nous n’avons pas retiré les humains du processus ; nous avons élevé leur rôle à celui de « Managers » de leurs collègues IA. Il existe deux points de contrôle humains critiques qui encadrent le flux de travail autonome :
La synchronisation d’alignement (Pré-travail) Avant qu’aucun code ne soit écrit, le Product Owner et l’ingénieur responsable se réunissent (virtuellement) pour itérer sur la story. L’objectif n’est pas de dicter les détails de mise en œuvre technique, mais de s’aligner sur le « quoi » et le « pourquoi ». Ils affinent les exigences jusqu’à ce que les deux parties soient satisfaites. Ce n’est que lorsque l’ingénieur marque explicitement la story comme « Prête pour le développement » que l’agent prend le relais.
2. La revue managériale (Post-travail) Une fois que l’agent a terminé la planification, le codage et les tests, il présente le travail pour une revue de production. L’ingénieur valide le résultat de la même manière qu’un bon manager vérifierait le travail d’un subordonné:
- Il inspecte le code final et les fonctionnalités.
- Ils inspectent le code final et les fonctionnalités.
- Ils fournissent des retours via la revue de code.
Si l’ingénieur repère un problème ou une meilleure approche, il laisse un retour. L’agent prend ce retour pour corriger le code immédiat, et de manière cruciale, génère une story d’auto-amélioration pour mettre à jour ses propres instructions afin que le même retour ne soit plus nécessaire la prochaine fois.
Cette responsabilité consolidée permet la rapidité tout en maintenant la qualité. La responsabilité n’est pas diffusée entre plusieurs équipes ; elle est concentrée auprès d’un ingénieur qui valide le travail de manière holistique.
Éliminer l’ancien processus
Notre PDG Orlin Radev le décrit simplement : « Nous n’avons pas simplement ajouté des outils IA en périphérie. Nous avons détruit et reconstruit notre processus de développement avec l’IA au cœur. »
Lisez la perspective complète d’Orlin sur ce que cela signifie pour les opérateurs de points de charge dans Comment AMPECO est devenu natif IA..
Nous avons annulé les sessions de grooming traditionnelles où une équipe d’ingénierie et le product manager discutaient de toutes les stories d’une itération. Au lieu de cela, nous avons des synchronisations d’alignement ciblées où les humains (un ingénieur et un product owner) définissent l’intention, et l’IA gère l’analyse technique. Nous avons supprimé les démos d’itération car les livraisons quotidiennes rendaient les présentations bihebdomadaires obsolètes. Nous sommes passés de sprints hebdomadaires à des versions quotidiennes continues.
Et les résultats prouvent que cela en valait la peine : une vélocité 4 fois plus rapide avec 50 % de bugs en moins par story. Nous n’avons pas échangé la qualité contre la rapidité, nous avons plutôt construit un système où les deux s’améliorent ensemble. Nous y sommes parvenus en appliquant PLUS de contrôles qualité, pas moins. La couverture des tests a augmenté tandis que la livraison s’accélérait.
Le changement stratégique : La vélocité comme avantage concurrentiel
Pour un CTO, le compromis « rapidité vs. fiabilité » est souvent le frein le plus important pour l’organisation. Lorsque les cycles de développement sont lents, la dette technique s’accumule car les équipes ne peuvent pas se permettre de refactoriser tout en respectant les dates de livraison. Lorsque la fiabilité est faible, la « taxe de maintenance »—gérer les incidents de production et les bugs—cannibalise la feuille de route.
En passant à un système natif IA, nous avons fait passer l’organisation d’une posture défensive à une posture offensive.
Lorsque les taux de bugs chutent de 50 % grâce à l’application automatisée, l’équipe d’ingénierie cesse d’être un centre de coûts pour les corrections et devient une usine d’innovation. Des cycles de développement 4 fois plus rapides ne signifient pas seulement « plus de fonctionnalités »—cela signifie que le coût de l’expérimentation a chuté. Nous pouvons maintenant intégrer des mises à jour réglementaires complexes ou des exigences de reporting personnalisées en quelques heures, répondant à des pressions du marché qui auraient paralysé une équipe traditionnelle pendant des semaines.
Le moteur auto-améliorant
Ce système crée un avantage cumulatif que les processus traditionnels ne peuvent égaler. Dans une organisation d’ingénierie standard, la connaissance est cloisonnée. Lorsqu’un développeur senior apprend une leçon, elle peut rester dans sa tête ou, au mieux, finir dans un wiki.
Dans un système natif IA, chaque leçon est codifiée. Chaque fois qu’un agent génère une story d’auto-amélioration basée sur les retours humains, cette connaissance est intégrée de manière permanente dans l’infrastructure. Le niveau de qualité de base de l’ensemble du département s’élève à chaque tâche.
Comme le dit Orlin : « Si nous avions commencé par créer des fonctionnalités IA pour les clients d’abord, nous aurions résolu le problème d’aujourd’hui. En reconstruisant le cœur, nous avons résolu le problème de demain. »
Construire vers l’intérieur pour avancer vers l’extérieur
Nous n’avons pas construit d’agents IA pour suivre une tendance. Nous les avons construits parce que notre propre processus d’ingénierie était le goulot d’étranglement de notre mission d’expansion de l’infrastructure de recharge de VE.
Parce que nos agents sont éprouvés sur notre propre code de production critique, nous avons un plan clair pour étendre les capacités de l’IA en amont—vers la réussite client, les opérations et l’automatisation produit. Ce ne seront pas des fonctionnalités spéculatives ; elles seront des extensions d’une architecture qui alimente déjà notre cœur.
Il y a six mois, nous nous sommes fixés pour objectif de prouver que rapidité et fiabilité pouvaient se renforcer mutuellement. Les données prouvent que c’est possible. L’écart entre l’ingénierie native IA et le développement traditionnel ne fait que commencer à s’ouvrir, mais il définira qui mènera dans la prochaine décennie du logiciel.
