La plupart des opérateurs qui ont sérieusement envisagé de changer de plateforme ont fait, sous une forme ou une autre, le même calcul : combien coûtent chaque année l’équipe et l’infrastructure actuelles, par rapport à ce qu’ils paieraient en frais pour un système de gestion des bornes de recharge (CPMS).
Cette comparaison a un angle mort. Les coûts les plus importants d’un CPMS interne n’apparaissent dans aucun budget. On ne les trouve ni dans la ligne des effectifs, ni sur la facture d’infrastructure cloud, ni dans les dépenses de conformité. Ils s’accumulent dans ce qui n’a pas été construit, dans les points de vue qui n’ont jamais pesé dans les décisions, et dans l’écart entre la situation actuelle de l’exploitation et ce qu’elle pourrait être.
La plupart des plateformes internes ont été développées à une époque où les alternatives commerciales n’étaient pas encore assez mûres pour qu’on leur confie les opérations essentielles. Le raisonnement initial reste valable ; ce qui a changé, c’est le calcul, et plus précisément les coûts qui n’ont jamais figuré sur une ligne budgétaire. Nous avons accompagné des changements de plateforme avec certains des plus grands opérateurs de bornes de recharge (CPO) d’Europe. Ce que les opérateurs découvrent, systématiquement, c’est que leur comparaison laissait de côté les coûts qui comptent le plus.
Le travail qui passe toujours en premier
Exploiter un CPMS interne signifie que votre équipe d’ingénierie assume des obligations récurrentes qu’aucune plateforme commerciale ne prend en charge à votre place. Mises à jour de protocoles, recertifications de paiement, cycles de conformité réglementaire : tout cela arrive dans le backlog comme du travail planifié, avant tout le reste, parce que ce sont le marché et les régulateurs qui fixent l’échéance, et non votre équipe produit.
Ces obligations s’alourdissent avec la taille du réseau : chaque nouveau marché, chaque fabricant de matériel ajouté, chaque juridiction avec son propre calendrier de conformité élargit le périmètre à maintenir. La capacité de l’équipe à le maintenir n’augmente pas au même rythme.
Le vrai coût, ce ne sont pas les heures elles-mêmes, mais ce qu’elles repoussent. Le travail mis de côté est justement celui qui ferait avancer l’entreprise. Le sprint de conformité est visible sur le tableau. L’élément de la feuille de route qu’il a repoussé ne l’est pas.
Votre activité telle qu’elle pourrait déjà être
Votre exploitation pourrait déjà être différente si la maintenance n’était pas toujours passée en premier. Des fonctionnalités inscrites à la feuille de route depuis dix-huit mois. Une capacité commerciale reportée au cycle suivant, puis au suivant encore. Des outils pour vos clients que votre équipe saurait construire, mais qu’elle n’a pas la disponibilité de commencer.
Rien de tout cela n’apparaît dans un audit, puisque cela n’a jamais existé. Vous pouvez examiner tout ce qui a été construit. Rien ne permet d’examiner ce qui ne l’a pas été.
Une partie de ce qui a été reporté est désormais une capacité standard chez les opérateurs avec lesquels vous êtes en concurrence. Une autre devient une attente commerciale sur les marchés où vous êtes présent. La feuille de route reportée ne crée aucune ligne de coût visible ; ses effets se manifestent par les capacités qui vous manquent lorsqu’une opportunité commerciale les exige.
Situez votre exploitation grâce au benchmark du CPMS interne.
Les repères qui ne viennent que de l’extérieur
Les équipes internes développent une véritable expertise de leur propre exploitation. Avec le temps, cette expertise s’accompagne d’un effet plus difficile à voir de l’intérieur : une dérive des repères. Sans points de référence externes, la perception qu’a l’équipe de ce qui est difficile, de ce qui est normal et de ce qui est vraiment propre à son réseau se replie sur elle-même, ce qui conduit à surestimer durablement la spécificité de ses besoins. Une logique de facturation sur mesure qui semble irremplaçable. Des cas particuliers liés au matériel qui paraissent d’une complexité unique. Des exigences de workflow qui semblent trop spécifiques pour qu’une plateforme standard puisse les prendre en charge.
Les opérateurs qui ont fait la transition décrivent tous, après coup, le même constat : l’essentiel de ce qui ressemblait à une complexité propre et irremplaçable n’était que la complexité normale de l’exploitation d’un grand réseau. Gestion du firmware d’une douzaine de fabricants de matériel, logique de facturation à plusieurs niveaux pour les contrats de flottes B2B, structures personnalisées d’identifiants d’itinérance : autant de défis que des dizaines d’autres opérateurs sur la même plateforme ont déjà relevés. Les solutions existaient. Elles étaient simplement invisibles de l’intérieur.
Les opérateurs qui s’appuient sur une plateforme commerciale présente sur 200+ réseaux acquièrent des repères structurellement inaccessibles au sein d’une seule exploitation : ce que les réseaux comparables ont déjà résolu, quelles capacités deviennent des exigences du marché avant d’apparaître dans un appel d’offres, vers où se dirige le secteur avant que le changement n’arrive. Une exploitation isolée, aussi bien gérée soit-elle, ne peut pas les acquérir.
Un savoir concentré sur trop peu de personnes
Chaque CPMS interne repose sur un petit groupe d’ingénieurs qui détiennent la véritable mémoire du système, une concentration due à l’ancienneté et aux circonstances plutôt qu’à un choix délibéré. Ils savent pourquoi une règle de facturation est codée en dur. Ils savent ce que le correctif de firmware de 2021 a changé et ce qu’il a laissé en suspens. Ils savent quel cas particulier lié au matériel exige un contournement qui n’a jamais été formellement documenté.
Le code qu’ils maintiennent a aussi accumulé des années de décisions prises sous la pression opérationnelle : des choix sensés sur le moment, dont l’effet cumulé fait que chaque modification future demande un peu plus d’effort qu’elle ne le devrait. McKinsey estime que la dette technique représente 20 à 40 % de la valeur de l’ensemble d’un parc technologique, une surcharge croissante qui apparaît rarement sur une ligne précise avant de devenir une contrainte.
Tout code volumineux construit pendant des années sous pression opérationnelle développe naturellement ce type de charge invisible. La fragilité qui en résulte est un risque pour la continuité de l’activité, pas seulement un problème technique. Lorsque ces ingénieurs partent (départs naturels, meilleures opportunités ou lassitude accumulée après des années en mode maintenance), le savoir ne se transmet pas proprement. Le manque de connaissances se révèle généralement au moment où l’exploitation est le moins en mesure de l’absorber : pendant une migration, une acquisition ou un sprint de conformité que personne n’avait budgété.
Si ce schéma vous semble familier, l’échange sur une preuve de concept (PoC) commence par votre architecture actuelle.
Un écart qui ne cesse de se creuser
Chacun de ces coûts pèse déjà à lui seul. Leur effet combiné est d’une autre nature.
Comme AMPECO est maintenu comme une plateforme unique pour l’ensemble de ses 200+ opérateurs simultanément, chaque capacité livrée leur parvient à tous en même temps : diagnostic des pannes assisté par l’IA, gestion dynamique des tarifs, intégrations de gestion de l’énergie, autant de capacités qui deviennent des exigences standard sur les marchés de vos clients. Pour un opérateur doté d’une plateforme interne, chacune entre dans le backlog comme un sujet à évaluer, cadrer, prioriser et finalement développer, seul, avec une équipe déjà mobilisée par le rattrapage.
La première année, il s’agit d’une ou deux fonctionnalités. À la troisième année, l’écart est significatif : un ensemble de capacités auxquelles vos concurrents ont accès et que votre équipe n’a pas encore atteintes dans le backlog. À la cinquième année, la question porte sur ce que votre entreprise peut proposer ou non : quels modèles commerciaux vous pouvez prendre en charge, quelles exigences du marché vous pouvez satisfaire, et ce que votre équipe d’ingénierie est en mesure de développer lorsque clients et concurrents avancent plus vite que votre backlog ne le permet.
La charge de rattrapage, la feuille de route reportée, l’absence de repères entre réseaux, la dette technique qui s’accumule : ces éléments ne s’additionnent pas simplement. Ils interagissent et se renforcent : la charge de rattrapage consomme la capacité qui permettrait de résorber le backlog ; le backlog reporté empêche le travail de feuille de route qui réduirait cette charge. L’écart entre une exploitation interne et une exploitation reposant sur une plateforme commerciale conçue pour absorber ces coûts de manière centralisée ne reste pas stable dans le temps.
Ce que constatent les opérateurs qui ont connu les deux
Les opérateurs qui ont fait cette transition avec AMPECO n’ont pas découvert ces coûts en théorie. Ils les ont reconnus après coup : dans les capacités dont ils ignoraient l’existence, dans les problèmes que d’autres avaient déjà résolus à leur insu, dans la feuille de route qui s’est remise en mouvement quelques mois après le changement, parce que la file de maintenance s’était enfin vidée.
Ce constat prend toujours la même forme : ils ignoraient ce qui était possible, car personne au sein d’une seule exploitation ne peut voir l’ensemble de ce que des exploitations similaires ont déjà résolu.
Avant d’en arriver à ces conclusions, certaines questions méritent d’être posées en interne :
- Quelle part de votre capacité d’ingénierie a été consacrée aux mises à jour de protocoles, à la conformité ou aux recertifications de paiement au cours des douze derniers mois ?
- Combien d’éléments de la feuille de route ont été reportés plus de deux fois ?
- Si les ingénieurs qui connaissent le mieux la plateforme partaient demain, combien de temps faudrait-il avant que l’exploitation en pâtisse ?
- Quelles capacités commerciales n’avez-vous pas développées ces deux dernières années, alors que vos concurrents sur des plateformes commerciales les proposent aujourd’hui ?
Ce constat peut venir avant que l’écart ne se creuse, ou après. La différence entre ces deux moments est importante : non pas par urgence, mais parce que l’équipe d’ingénierie a encore la capacité de piloter la transition plutôt que de la subir.
À lire aussi :
Développer son propre CPMS ne se justifie plus : l’analyse stratégique des raisons pour lesquelles le calcul a changé, rédigée pour la direction générale et le conseil d’administration.
Toujours en rattrapage : pourquoi les équipes d’ingénierie d’un CPMS interne ne peuvent pas prendre d’avance : la raison structurelle de la charge de maintenance, pourquoi recruter davantage ne la résout pas, et ce qui change lorsque la file des obligations passe à la plateforme.
