AMPECO n’est pas devenu nativement doté d’IA du jour au lendemain. Le changement a commencé par une question simple mais ambitieuse : et si l’IA pouvait faire plus qu’assister les développeurs ? Et si elle pouvait réellement écrire du code prêt pour la production, pendant que les ingénieurs se concentrent sur l’architecture, la validation et l’orientation plutôt que sur les tâches d’implémentation répétitives ?
Cette idée est rapidement devenue une véritable réflexion en interne. À mesure que le rythme de l’innovation s’accélérait et que les attentes en matière de rapidité continuaient de croître, il est devenu clair que les workflows de développement traditionnels étaient le véritable goulot d’étranglement — pas le talent, pas l’ambition, mais le moteur lui-même.
À l’été 2025, nous avions reconstruit l’ensemble de notre workflow de développement autour d’agents IA — inspirés en partie par des recherches sur les architectures d’agents longue durée qui maintiennent l’état et le contexte sur plusieurs sessions.
Ce changement nous a forcés à repenser fondamentalement la façon dont les logiciels sont conçus. Plutôt que de choisir entre rapidité et sécurité, nous nous sommes demandé s’il était possible d’éliminer entièrement ce compromis. La réponse ne résidait pas dans de meilleurs outils individuels, mais dans une intégration profonde de l’IA au cœur de la façon dont AMPECO conçoit, construit et fait évoluer sa plateforme.
Pour les opérateurs de bornes de recharge, cette transformation a des implications directes. Voici ce que la plupart des CPO ne voient pas : le moteur de développement sous votre plateforme est une contrainte cachée sur votre rapidité concurrentielle. Chaque fois que vous avez attendu des mois pour une intégration critique, ou renoncé à une fonctionnalité ou une opportunité de marché parce qu’« elle n’est pas dans la roadmap », vous avez ressenti cette contrainte.
Vous ne saviez simplement pas qu’elle pouvait être résolue.
Le paradoxe rapidité/sécurité
Dans les infrastructures critiques, le biais du secteur en faveur de la prudence était rationnel. Les longs cycles de publication, les revues manuelles approfondies et la gestion conservatrice des changements étaient la manière la plus sûre d’opérer lorsque le marché de la recharge VE était jeune et les alternatives limitées.
Le profil de risque a changé.
Le marché de la recharge VE arrive rapidement à maturité. La concurrence s’intensifie, les attentes des clients augmentent, les exigences de conformité évoluent plus vite et les modèles économiques se diversifient.
Les CPO ont toujours besoin des mêmes fondamentaux : un déploiement rapide des fonctionnalités pour rester compétitifs, un taux de disponibilité élevé, l’intégration avec de nouveaux matériels et systèmes énergétiques, et la capacité de s’adapter à l’évolution du marché.
Ce qui change, c’est la pression. La rapidité ne peut pas se faire au détriment de la stabilité, et la stabilité ne doit pas freiner l’innovation. Les CPO ont besoin des deux en même temps.
La réalité de l’iceberg
Lorsqu’ils évaluent les plateformes, la plupart des CPO se concentrent sur le visible : les fonctionnalités, les prix et la qualité du support. Mais ce que vous voyez n’est que la partie émergée de l’iceberg. Tout aussi important est un élément moins visible : la manière dont votre fournisseur conçoit et livre réellement les logiciels.
Le moteur de développement sous-jacent détermine tout ce qui compte dans la durée. Il détermine la rapidité avec laquelle de nouvelles capacités arrivent lorsque vous en avez besoin. Si la rapidité se fait au prix de la stabilité, ou si les deux progressent ensemble. La flexibilité dont votre plateforme peut faire preuve à mesure que votre activité évolue.
Cela nous a conduits à poser une question fondamentale : que faudrait-il pour éliminer entièrement le compromis rapidité / sécurité ? Pas seulement l’améliorer, mais le résoudre ?
Nous avons compris que la contrainte n’était pas notre talent — nous avons des ingénieurs exceptionnels. Ce n’était pas notre engagement — notre équipe a toujours travaillé dur. La contrainte était le moteur de développement lui-même.
Cela a renforcé notre conviction que la façon la plus impactante d’intégrer l’IA à la plateforme AMPECO était de l’intégrer en notre cœur même. Nous avons donc fait quelque chose de radical. Nous avons reconstruit l’ensemble de notre processus de développement pour qu’il soit nativement doté d’IA — pas assisté par l’IA, pas enrichi par l’IA, mais nativement doté d’IA depuis la base.

Comment nous avons reconstruit notre moteur de développement depuis la base et sommes devenus nativement dotés d’IA
Soyons clairs sur ce que nous entendons par « nativement doté d’IA », car le terme est beaucoup utilisé.
De nombreux produits intègrent aujourd’hui des fonctionnalités d’IA, comme des chatbots, des moteurs de recommandation ou des rapports automatisés. Ce sont des fonctionnalités d’IA — visibles pour les utilisateurs, présentes dans les supports marketing, et ce que tout le monde se précipite à livrer.
Le natif IA est tout autre chose. C’est de l’IA intégrée dans la façon dont vous concevez les logiciels, pas dans ce que le logiciel fait. C’est invisible pour vos clients, mais cela transforme tout ce que vous pouvez leur offrir.
La différence compte. Ajouter des fonctionnalités d’IA à un produit conçu de manière traditionnelle, c’est comme mettre un moteur plus puissant dans une voiture à boîte manuelle — vous gagnez un peu, mais vous restez limité par le système sous-jacent. Reconstruire la façon dont vous concevez les logiciels avec l’IA, c’est comme passer à un tout autre système de propulsion. Les contraintes changent fondamentalement.
Lorsque nous avons proposé cette transformation pour la première fois, nos ingénieurs étaient très sceptiques — et pour de bonnes raisons. Nous avons toujours privilégié des solutions stables et prévisibles. Et quand la plupart des développeurs entendent « coder avec l’IA », ils pensent au « vibe coding » : solliciter une IA jusqu’à ce que le résultat semble correct, puis le livrer en espérant que tout se passe bien.
Cette approche ne fonctionne pas pour les infrastructures critiques.
Le vibe coding convient aux prototypes et aux preuves de concept. Mais pour un logiciel qui gère des infrastructures de recharge, il faut un processus systématique où la qualité est imposée à chaque étape, pas espérée à la fin.
Nous devions déterminer en quoi consistait cette approche. À quoi ressemble réellement un développement IA systématique et prêt pour la production ?
Nous sommes donc partis des premiers principes.
La création du CoOperator Dev Agent
La question clé n’était pas « l’IA peut-elle écrire du code ? ». C’était « où les humains créent-ils réellement de la valeur dans le développement logiciel ? ».
Nous sommes partis d’un principe simple : les humains excellent dans la conceptualisation et le jugement, l’IA excelle dans l’exécution. Comprendre ce qui doit être construit, concevoir son fonctionnement, valider qu’il fonctionne correctement — c’est le jugement humain. Traduire ces décisions en code, exécuter les tests, déployer les changements — c’est l’exécution.
Nous avons codifié l’ensemble de notre workflow autour de ce principe. Le résultat est le CoOperator Dev Agent : un système de gestion de workflow où l’IA gère l’exécution pendant que les ingénieurs dirigent l’architecture et valident la qualité. Pour le plan technique de la façon dont nous avons construit le CoOperator Dev Agent, consultez l’analyse approfondie de notre CTO, Alexander Alexiev, dans How We Built An AI-Native Engineering System.

Avec plus de 20 000 tests unitaires automatisés, chaque changement est validé avant la production. Il ne s’agit pas d’espérer que l’IA a vu juste, mais d’une assurance qualité systématique.
Le changement de mentalité
Construire le CoOperator Dev Agent était la partie facile. La transformation la plus difficile a été le changement de mentalité nécessaire dans tout notre département d’ingénierie.
Nous demandions aux ingénieurs d’arrêter de faire ce qu’ils avaient mis des années à maîtriser. Arrêter d’écrire du code ligne par ligne. Commencer à concevoir des systèmes et à diriger l’exécution de l’IA à la place.
Le changement ne concerne pas seulement ce que font les ingénieurs ; il porte sur leur niveau d’abstraction. Avant, ils traduisaient des exigences humaines en code. Désormais, ils traduisent les exigences en instructions pour l’IA, puis valident les résultats. C’est un niveau de réflexion plus élevé, qui requiert la même compréhension technique approfondie, mais appliquée différemment.

Les ingénieurs sont passés de « maçons » écrivant de la syntaxe à « architectes » orchestrant la logique. Ils n’écrivent plus le code ligne par ligne. Leur niveau d’abstraction revient au langage humain — mais un langage humain qui sera lu par un agent IA.
Notre ancien goulot d’étranglement : trop de choses à construire, pas assez d’ingénieurs. Notre nouveau goulot d’étranglement ? Disposer d’exigences vérifiées et bien justifiées. Quand le code n’est plus la contrainte, savoir exactement quoi construire devient la contrainte.
C’est pourquoi nous rapprochons tous nos ingénieurs de la réflexion produit. Au lieu d’une poignée de chefs de produit alimentant un pipeline pour des dizaines d’ingénieurs, nous évoluons vers un modèle où les ingénieurs explorent, recherchent, expriment une intention et prennent les décisions qui façonnent un excellent produit. CoOperator s’occupe de l’implémentation.
Comme le résume simplement Alexander : « Écrire du code manuellement est devenu obsolète. L’expertise réside désormais dans l’amélioration de l’automatisation, pas dans les tâches de codage répétitives. » Il détaille l’architecture technique et le workflow complets dans How We Built An AI-Native Engineering System.
Les résultats: rapidité et qualité ensemble
L’impact a été spectaculaire.
Des stories qui prenaient deux jours se terminent désormais en quelques heures. Nous sommes passés de sprints hebdomadaires à des publications quotidiennes. Nous livrons deux fois plus de fonctionnalités avec deux fois moins de bugs.
Cette dernière partie surprend. Mais les données sont claires : notre taux de bugs diminue de mois en mois depuis que nous avons commencé. Pourquoi ? Parce que l’IA ne se fatigue pas, ne prend pas de raccourcis et ne saute pas les tests. Et nous ne faisons que commencer.

Une infrastructure sans latence : l’impact pour les CPO
Dans le développement logiciel, il y a toujours de la latence. De la latence entre l’identification d’un besoin et sa planification. Entre la planification et le début du développement. Entre le développement et les tests. Entre les tests et le déploiement.
Ces latences s’additionnent. Une fonctionnalité qui prend des jours à construire peut prendre des mois à être livrée.
Lorsque votre fournisseur de plateforme de recharge VE devient nativement doté d’IA, ces latences s’effondrent. Pas jusqu’à zéro, car il y a toujours des contraintes, mais jusqu’à quelque chose de fondamentalement différent.
C’est une infrastructure sans latence, où vos besoins se traduisent en capacités de plateforme sans les délais traditionnels qui freinent votre activité.
Voici ce que cela signifie en pratique:
1. Une résolution des incidents plus rapide et plus fiable
Notre vélocité de développement a fondamentalement changé. Des stories qui prenaient auparavant deux jours se terminent désormais en quelques heures, et avec des publications quotidiennes, les améliorations atteignent la production en continu plutôt que d’attendre des fenêtres hebdomadaires.
Tout aussi important, 50 % de bugs en moins par story signifie moins de problèmes perturbant vos opérations dès le départ. Et lorsqu’un incident survient, sa résolution est 3 à 4 fois plus rapide qu’avant.
Cette rapidité ne se fait pas au détriment de la qualité, car nos tests systématiques nous permettent de livrer des correctifs en continu sans augmenter le risque.
2. Une livraison des fonctionnalités et une vélocité d’intégration plus rapides
Une vélocité de développement plus élevée se traduit directement par un délai de mise en valeur plus court. Qu’il s’agisse d’intégrer un nouveau processeur de paiement, d’une fonctionnalité de reporting sur mesure ou d’une mise à jour de conformité réglementaire, les délais se sont considérablement réduits.
Avec des cycles de développement jusqu’à 4 fois plus rapides, des intégrations et des publications de fonctionnalités qui prenaient autrefois des trimestres peuvent désormais être livrées en quelques semaines. Les délais réels dépendent toujours de la complexité et des priorités, mais le point de référence a fondamentalement changé : répondre aux besoins du marché et de l’entreprise se mesure désormais en semaines, pas en trimestres.
3. Une fiabilité de plateforme qui se renforce avec le temps
Moins d’incidents en production perturbant les opérations, moins de temps consacré aux escalades et un comportement de plateforme plus prévisible. L’amélioration de la stabilité provient du même système qui crée la vélocité — des contrôles qualité automatisés et des tests complets intégrés à chaque changement.
Mais voici ce qui distingue cela du développement traditionnel : le CoOperator Dev Agent apprend et gagne en efficacité à chaque cycle, et cet avantage se cumule. Lorsqu’un problème est identifié, nous ne corrigeons pas seulement ce bug précis — nous améliorons les instructions et le contexte du système d’IA, relevant le niveau de qualité de référence pour tous les développements futurs.
4. La flexibilité stratégique devient réalité
économique, et non l’inverse. À mesure que la contrainte du développement de la plateforme passe de « à quelle vitesse pouvons-nous construire » à « que devons-nous construire », nous pouvons répondre à l’évolution des besoins de l’entreprise — qu’il s’agisse de nouveaux modèles tarifaires, d’offres de services ou de segments de marché — sans les goulots d’étranglement traditionnels du développement. Cela signifie que notre plateforme ne dicte pas votre stratégie — elle la rend possible.
À mesure que nous avons libéré la vitesse de développement, nous avons repoussé les contraintes. Nous automatisons désormais les traductions, la documentation et les processus de publication, et rationalisons tout ce qui crée de la latence entre « fonctionnalité terminée » et « valeur livrée au client ».
Pourquoi cela compte au-delà d’AMPECO
Le moteur de développement sous votre plateforme détermine tout ce qui se cumule avec le temps : la rapidité avec laquelle les capacités arrivent, le fait d’être ou non contraint de choisir entre rapidité et stabilité, et l’adaptabilité de votre infrastructure à mesure que votre activité évolue.
L’iceberg compte plus que sa pointe.
L’ingénierie nativement dotée d’IA n’est pas facile. Elle exige une transformation fondamentale : repenser l’architecture des processus de développement, investir massivement dans les tests automatisés, opérer un changement culturel dans les équipes d’ingénierie et améliorer en continu les systèmes d’IA eux-mêmes.
Mais elle relève la barre de ce que les CPO devraient attendre de chaque fournisseur de plateforme. Le « natif IA » devrait devenir la nouvelle norme. Le faux choix entre rapidité et sécurité est révolu. Le développement nativement doté d’IA — où une infrastructure sans latence offre les deux — est possible aujourd’hui, pas dans un futur lointain.

