Lorsque la première génération d’opérateurs de bornes de recharge (CPO) a commencé à étendre ses réseaux, faire appel à un CPMS (système de gestion des bornes de recharge) commercial n’était pas une option crédible. Les plateformes disponibles en étaient à leurs débuts, souvent liées à certaines familles de matériel, et rarement conçues pour la complexité à laquelle un opérateur en croissance faisait réellement face : structures tarifaires sur plusieurs marchés, itinérance entre de multiples acteurs, intégrations de facturation d’entreprise, matériel de fabricants qui refusaient de certifier le logiciel d’un tiers.
Les opérateurs ont donc développé leur propre plateforme. C’était une décision rationnelle. Une équipe interne disposant des moyens nécessaires pouvait construire un outil parfaitement adapté aux besoins de l’entreprise, sans contraintes imposées par un fournisseur ni feuille de route dictée par les clients et les priorités d’un autre. Le marché des CPMS commerciaux n’avait pas encore produit de plateforme à laquelle confier le cœur des opérations d’un opérateur.
Ces plateformes ont rempli une réelle fonction. Beaucoup gèrent encore aujourd’hui des milliers de bornes de recharge. Les raisons de les développer étaient solides. Ce qui a changé, c’est la question de savoir si ce raisonnement tient toujours.
Un scénario que l’industrie du logiciel connaît déjà
Il y a vingt ans, une transition comparable s’est jouée dans les logiciels d’entreprise, portée par les mêmes conditions structurelles : une catégorie qui a mûri plus vite que les acteurs en place ne l’avaient prévu, et un choix rationnel qui a évolué avec elle. Les entreprises qui utilisaient des outils CRM développés sur mesure ne commettaient pas d’erreur. Les alternatives commerciales étaient soit immatures, soit, dans le cas de Siebel, fondées sur des modèles de licence et des cycles de mise en œuvre irréalistes pour la plupart des organisations sans budget de conseil dédié. Construire un outil adapté aux besoins réels de l’entreprise était le choix rationnel.
L’arrivée de Salesforce n’a pas simplement apporté un meilleur produit. Elle a fait mûrir la catégorie au point de changer le calcul. Siebel a atteint son pic en 2002 avec 45 % du marché du CRM. Quatre ans plus tard, la norme avait complètement changé. Les entreprises qui ont continué à développer et à maintenir leur propre infrastructure CRM après ce tournant ne défendaient pas un principe ; elles absorbaient une charge d’ingénierie qui n’avait plus de sens sur le plan concurrentiel. Personne ne leur reproche d’avoir développé leur outil au départ ; la catégorie a mûri autour d’elles et le choix rationnel a évolué.
Le marché des CPMS vit la même transition. Pour les opérateurs qui exploitent des plateformes propriétaires, la catégorie a atteint sa maturité. Reste à savoir s’il faut agir tant que les options sont encore ouvertes, ou attendre que la plateforme devienne une contrainte opérationnelle sérieuse.
AMPECO repose sur ce principe : la maintenance de l’infrastructure est assurée de manière centralisée pour 200+ opérateurs, tandis que chaque réseau développe et détient ses propres fonctionnalités différenciantes.
Ce qui a réellement changé
Trois éléments ont nettement évolué depuis que la plupart des décisions de CPMS interne ont été prises.
Les plateformes commerciales ont beaucoup progressé depuis 2016
La plupart des opérateurs qui ont étudié le marché commercial à l’époque et jugé les offres trop immatures, trop rigides ou trop dépendantes du matériel avaient raison. Le problème, c’est que nombre d’entre eux n’ont jamais réexaminé cette conclusion depuis. Ce qui est disponible aujourd’hui sur le marché diffère sensiblement de ce qui existait lorsque la plupart des décisions de développement en interne ont été prises : une couverture d’API plus large, une réelle indépendance vis-à-vis du matériel et la capacité d’absorber les évolutions réglementaires au niveau de la plateforme au lieu de les transférer à l’équipe de chaque opérateur.
Les obligations réglementaires se sont nettement alourdies
La conformité AFIR des terminaux de paiement est entrée en vigueur en avril 2024. La norme ISO 15118-20 est devenue obligatoire pour la recharge publique en janvier 2026. Elle le sera pour les réseaux semi-publics et privés en janvier 2027. L’OCPP 2.0.1 (Open Charge Point Protocol) est déjà un critère de sélection dans les appels d’offres publics en Europe du Nord, et de plus en plus dans la région DACH. Pour une équipe interne, chacune de ces obligations représente un sprint d’ingénierie à part entière. La charge cumulée de sprints sur une période de 36 mois n’est pas une projection pour un opérateur qui maintient une plateforme propriétaire : c’est son backlog actuel. Chaque obligation mobilise du temps d’ingénierie planifié qui ne peut pas servir en même temps à l’entrée sur de nouveaux marchés, à des fonctionnalités génératrices de revenus ou à l’amélioration de l’expérience des conducteurs de véhicules électriques (VE).
Les grands opérateurs commencent à changer de cap
L’argument en faveur du développement en interne a toujours tiré une partie de sa force du fait que les pairs faisaient le même choix. Cette dynamique est en train de changer. Evolt, fournisseur britannique de recharge des VE qui exploite plus de 10 000 bornes de recharge et a investi pendant quinze ans dans sa plateforme propriétaire, a étudié le marché commercial en 2025 et a conclu qu’il avait atteint le niveau requis. L’ingénieur chargé de la due diligence technique d’Evolt a décrit l’écart avec les alternatives comme étant « énorme ». Lorsque des opérateurs de cette taille font un autre choix, le raisonnement qui soutenait le consensus en faveur du développement en interne perd de sa force.
Piégés par la maintenance
Le problème de fond des plateformes internes n’est pas qu’elles tombent en panne. Le modèle empêche structurellement les équipes d’ingénierie de prendre de l’avance sur le marché, car le travail nécessaire pour maintenir la plateforme à jour passe toujours en premier. Chaque année apporte son lot de nouvelles obligations : mises à jour de version OCPP, spécifications d’itinérance OCPI (Open Charge Point Interface), exigences de conformité, certifications de terminaux de paiement. Elles s’accumulent avec chaque nouveau marché et chaque nouveau cycle réglementaire.
Le résultat est prévisible. L’équipe qui avait construit la plateforme pour faire tourner l’activité réoriente peu à peu son temps. Non pas parce que quelqu’un a fait un choix stratégique délibéré, mais parce que la file de maintenance grandit plus vite que le backlog d’innovation ne se résorbe. Quand une échéance réglementaire approche, elle prend la priorité sur la fonctionnalité prévue au deuxième trimestre. Quand une mise à jour de firmware casse un cas limite matériel, les ingénieurs qui le corrigent sont ceux-là mêmes qui devaient concevoir la suite.
Ce que le marché attend désormais
Lorsque la plupart des plateformes CPMS internes ont été construites, les attentes envers les opérateurs de recharge des VE étaient nettement plus faibles. Les conducteurs acceptaient les imperfections ; les investisseurs considéraient le secteur comme une infrastructure de long terme, sans pression de résultats à court terme ; les régulateurs rédigeaient encore les règles qui allaient imposer des protocoles et des normes de paiement précis.
Cette fenêtre s’est rétrécie. Sur les marchés matures d’Europe du Nord et de l’Ouest et de la région DACH, elle s’est en grande partie refermée.
Les investisseurs qui évaluent aujourd’hui les opérateurs de recharge des VE appliquent la même grille de lecture qu’à toute entreprise de services qui opère à grande échelle : des marges prévisibles, un faible coût de service et une feuille de route produit axée sur la différenciation plutôt que sur l’entretien de l’infrastructure. Une équipe d’ingénierie dont la capacité est absorbée par la maintenance de la plateforme devient une ligne de frais généraux au compte de résultat, qu’il faut justifier activement devant le conseil d’administration. Les opérateurs qui peuvent démontrer des opérations allégées, une disponibilité élevée et une capacité de développement orientée vers leur véritable positionnement sur le marché sont plus crédibles que ceux qui absorbent encore la conformité avec des effectifs internes, et cette différence se reflète dans la manière dont les investisseurs modélisent l’activité.
Les attentes des conducteurs ont atteint un niveau comparable. Des sessions de recharge fiables sur tous les types de matériel, un traitement des paiements sans friction, une itinérance qui fonctionne comme annoncé : rien de tout cela n’impressionne plus un conducteur aujourd’hui, mais la moindre défaillance génère des plaintes qui restent visibles dans les résultats de recherche pendant des mois.
Le coût du statu quo est rarement calculé
La plupart des opérateurs qui ont étudié une migration finissent par faire le calcul complet : combien d’effectifs d’ingénierie sont réellement consacrés à la maintenance de la plateforme, ce qu’a coûté le report répété des fonctionnalités du backlog, quel retard le cycle de conformité accuse par rapport aux exigences actuelles du marché, et ce que cet écart coûtera en 2027.
Le regret, quand il survient, porte rarement sur le développement initial. Il porte sur le coût croissant d’une décision qui semblait réglée mais ne l’était pas : la charge accumulée du statu quo, et non la logique du choix initial.
La décision de rester sur une plateforme interne est rarement délibérée. Elle s’installe par défaut, jusqu’à ce qu’un événement rende son coût visible pour la direction. Une échéance réglementaire manquée. Une période difficile après le départ d’un ingénieur senior qui détenait des années de connaissances sur la plateforme. Un concurrent qui lance des fonctionnalités en attente dans votre backlog depuis dix-huit mois.
Les opérateurs qui étudient une migration avant ces tournants disposent de la plus grande marge de manœuvre. Le calendrier n’est pas contraint, l’équipe plateforme est encore mobilisée et le périmètre de la transition peut être défini correctement au lieu d’être dicté par une crise. Ceux qui attendent se retrouvent avec une équipe plateforme épuisée, un calendrier écourté par une crise en cours et un dossier interne bien plus difficile à défendre.
La question à se poser
Les opérateurs qui ont développé en interne ont fait le bon choix compte tenu des conditions de l’époque. Il ne s’agit pas de dire qu’ils avaient tort ; il s’agit de constater que les conditions ont changé, et que le choix rationnel a évolué avec elles.
La question à se poser n’est pas historique : c’est ce que la plateforme coûte aujourd’hui. Non pas en comparant des frais de licence, mais en capacité d’ingénierie consacrée à une infrastructure standard plutôt qu’à la différenciation, en sprints réglementaires plutôt qu’en conquête de nouveaux marchés, en mode maintenance plutôt qu’en prise d’avance.
Pour faire ce calcul pour votre activité (ce que coûte la charge liée à l’infrastructure standard, ce qu’elle empêche de construire et où se situe la plateforme actuelle face aux meilleures plateformes du marché), le benchmark des CPMS internes dresse le tableau selon sept dimensions fonctionnelles.
Si cette question mérite d’être examinée dans votre organisation, ces articles en approfondissent certains aspects :
Sur quoi travaillent vraiment vos ingénieurs CPMS internes ? : la méthode pour répartir la charge de travail de votre équipe entre infrastructure standard et différenciation, et à quoi ressemble réellement le tableau sur la plupart des sprint boards internes.
Les coûts d’un CPMS interne dont personne ne parle : les coûts qui n’apparaissent sur aucune ligne budgétaire, et les questions à poser à votre direction avant que l’écart ne se creuse davantage.
