5 raisons pour lesquelles on ne peut pas « vibe coder » une plateforme EPM

Le « vibe coding » est devenu une expression courante pour désigner une évolution importante dans la manière dont certains logiciels sont développés : vous décrivez en langage naturel ce que vous voulez, un modèle d’IA génère l’implémentation, puis vous itérez à l’intuition plutôt qu’à partir de spécifications précises. Pour des prototypes, des outils internes ou des scripts jetables, c’est très efficace. Une phrase suffit pour obtenir une fonctionnalité opérationnelle et la mettre en production avant le déjeuner.

La gestion de la performance d'entreprise (EPM) n’appartient pas à cette catégorie de logiciels. Les plateformes EPM sont au cœur des chiffres sur lesquels une entreprise s’appuie pour construire ses plans financiers, fournir ses prévisions, mettre en place ses contrôles et présenter ses résultats au conseil d’administration. Elles modélisent la manière dont le chiffre d’affaires, les effectifs et la trésorerie évoluent dans l’entreprise, à travers des dizaines de dimensions, des centaines de scénarios et des milliers de formules interdépendantes. L’écart entre « une IA a généré quelque chose qui semble correct » et « une IA a généré quelque chose qu’un CFO peut défendre devant son conseil d’administration » est immense. Et cet écart ne disparaît pas simplement parce que les modèles deviennent meilleurs pour écrire du code.

Voici cinq raisons pour lesquelles cet écart est structurel, et non temporaire.

1. En finance, il n’existe pas de « presque correct »

La plupart des logiciels peuvent tolérer une certaine marge d’erreur. Un moteur de recommandation précis à 92% reste utile. Une interface qui s’affiche imparfaitement sur un navigateur peut tout de même être mise en production. Le vibe coding prospère précisément grâce à cette tolérance : on itère, on vérifie rapidement le résultat à l’œil et on déploie dès que cela semble fonctionner.

Les modèles financiers, eux, n’ont pas cette marge de manœuvre. Un moteur de calcul qui effectue correctement une conversion de devises dans 99% des cas n’est pas « correct à 99% » : il est faux. Car le 1% restant finit par apparaître sous la forme d’un écart dans une présentation au board ou d’une variation impossible à expliquer lors d’un audit. Les chiffres doivent concorder exactement, à chaque fois, pour chaque agrégation, chaque devise, chaque règle d’allocation et chaque période. Pour un bilan, « suffisamment proche » n’existe pas.

C’est là que réside l’incompatibilité fondamentale. Le vibe coding optimise la production d’un résultat qui semble plausible et qu’un humain valide rapidement d’un coup d’œil. L’EPM exige un résultat déterministe, démontrablement exact, validé par rapprochement avec les systèmes sources et les périodes précédentes. Un modèle d’IA qui génère une logique de formule à partir d’un prompt peut produire quelque chose qui s’exécute sans erreur tout en étant discrètement, et potentiellement gravement, faux : un signe incorrect, une mauvaise devise, une hypothèse erronée sur le calendrier fiscal… Rien dans le fait que « cela semble correct » ne permettra de détecter ces erreurs. Seuls des tests rigoureux à partir de chiffres de référence peuvent les révéler. Or cette discipline de test est précisément ce que les workflows de vibe coding tendent à contourner.

2. Le modèle de données est le produit - et il est réellement complexe

La véritable complexité d’une plateforme EPM ne réside ni dans ses écrans ni dans ses boutons. Elle se trouve dans le modèle de données multidimensionnel qui les sous-tend : hiérarchies d’entités, comptes, périodes, scénarios, versions et dimensions personnalisées telles que les lignes de produits ou les centres de coûts. Toutes ces dimensions doivent s’agréger correctement, permettre des ajustements à différents niveaux, prendre en charge des scénarios alternatifs et rester cohérentes lorsqu’une entreprise réorganise sa structure en plein exercice fiscal.

Concevoir correctement ce modèle nécessite de comprendre la manière dont les équipes Finance raisonnent réellement sur la planification - pas seulement ce qu’exprime une demande fonctionnelle en surface. Lorsqu’un utilisateur demande « la possibilité de modéliser différents scénarios d’effectifs par département », les véritables exigences sous-jacentes sont bien plus nombreuses : comment les scénarios interagissent-ils avec les données réelles ? Que deviennent les formules faisant référence à un scénario supprimé ? Comment les conversions de devises et d’unités s’appliquent-elles entre les différentes branches d’un scénario ? quelles permissions distinguent un utilisateur autorisé à modifier un scénario d'un utilisateur qui peut uniquement le consulter ? Comment l’ensemble se comporte-t-il lorsque le modèle contient 50 000 cellules et que cinq personnes travaillent dessus simultanément ?

Le vibe coding consiste à traduire rapidement une intention décrite en code. Il est conçu pour répondre à une intention explicite, pas pour faire émerger les implications structurelles de deuxième ou troisième ordre qu’un expert métier identifierait avant même d’écrire une ligne de code. On ne construit pas un modèle dimensionnel correct « au feeling », car sa robustesse dépend précisément de contraintes qui ne figurent pas dans le prompt initial. Elles apparaissent dans les cas limites : que se passe-t-il lorsqu’une hiérarchie change ? Lorsque deux scénarios fusionnent ? Lorsque le système passe à l’échelle ?

3. Le calcul multi-utilisateur en temps réel est un problème d’ingénierie, pas de génération

Les plateformes EPM modernes permettent à des dizaines d’utilisateurs Finance et métiers de travailler simultanément sur un même modèle : une personne modifie un driver commercial, une autre teste un scénario de coûts, tandis qu’une troisième observe la vue consolidée se mettre à jour quasiment en temps réel. Derrière cette expérience se trouve un moteur de calcul qui doit déterminer, à chaque modification, quelles cellules dépendantes - potentiellement des millions - doivent être recalculées. Il doit le faire suffisamment rapidement pour que la plateforme reste réactive, tout en garantissant la justesse du résultat lorsque plusieurs utilisateurs modifient simultanément des données liées.

Il s’agit d’un problème de systèmes distribués et de graphes de dépendances. Le résoudre correctement demande des années de travail à des équipes d’ingénierie spécialisées, avec une attention particulière portée au cache, au recalcul incrémental, à la résolution des conflits et à la reprise sur incident.

Ce n’est pas le type de problème que l’on résout en décrivant une fonctionnalité puis en acceptant ce qu’un modèle d’IA produit. Le vibe coding génère généralement du code qui fonctionne dans le cas de démonstration : un seul utilisateur, un petit volume de données, un scénario nominal. Mais les défaillances réellement critiques pour une plateforme EPM apparaissent sous charge concurrente, à grande échelle et dans la durée - précisément les conditions qu’une boucle rapide de génération puis de validation visuelle ne teste jamais.

Vous pouvez vibe coder un formulaire de saisie ressemblant à une feuille de calcul. Vous ne pouvez pas vibe coder un moteur de recalcul qui reste fiable et performant lorsqu’il constitue l’infrastructure sur laquelle une organisation planifie son année.

4. L’auditabilité et la gouvernance ne sont pas des fonctionnalités : elles sont au cœur du produit

Une grande partie de ce qu’une plateforme EPM doit réellement accomplir n’est pas visible dans une démonstration. Chaque chiffre doit pouvoir être retracé jusqu’à sa source. Chaque modification apportée à un modèle doit pouvoir être attribuée à une personne et à un instant précis. Chaque version doit pouvoir être reconstruite. Et chaque règle d’autorisation doit résister à l’examen d’un auditeur interne ou externe. Les équipes finance et comptabilité ssont soumises à des obligations de conformité qui n’ont rien à voir avec le fait que le logiciel « fonctionne » au sens large. La question est de savoir s’il est capable de démontrer ce qui s’est produit, quand cela s’est produit et qui en était responsable.

C’est ici que la vitesse du vibe coding devient un risque plutôt qu’un avantage. Générer rapidement du code à partir d’un prompt, sans concevoir délibérément l’architecture autour des pistes d’audit, des journaux de modifications, du contrôle d’accès basé sur les rôles et de la traçabilité des données, conduit généralement à des systèmes où cette infrastructure est soit absente, soit ajoutée de manière incohérente d’une fonctionnalité à l’autre. Ajouter après coup une gouvernance robuste à un système qui n’a pas été conçu autour de ces principes coûte beaucoup plus cher que de les intégrer dès le départ. Et pendant ce temps, la plateforme reste exposée précisément sur les sujets où un système financier peut le moins se permettre de l’être.

On ne peut « vibe coder » ni une conformité SOC 2, ni une piste d'audit fiable. Ces garanties proviennent de décisions d’architecture délibérées, prises avant la mise en production de la première fonctionnalité et non pas d’une série d’itérations sur un prompt jusqu’à ce que le résultat paraisse satisfaisant.

5. Les erreurs d’intégration restent invisibles… jusqu’à ce qu’elles deviennent catastrophiques

Les plateformes EPM ne fonctionnent pas en vase clos. Elles récupèrent les données réelles depuis un ERP, les données d’effectifs depuis un système RH, les informations CRM pour modéliser le chiffre d’affaires, puis doivent synchroniser ces données selon un calendrier défini, gérer les changements de schéma, rapprocher les écarts et alerter quelqu’un lorsqu’un flux est interrompu plutôt que de laisser de mauvaises données contaminer silencieusement les prévisions. Cette couche d’intégration est peu spectaculaire. Pourtant, elle est à l’origine d’une grande partie des défaillances EPM rencontrées dans le monde réel. Le problème ne vient pas nécessairement de la logique de modélisation. Il peut simplement s’agir d’un flux de données qui a cessé de se mettre à jour trois semaines plus tôt sans que personne ne s’en aperçoive, jusqu’au moment où les chiffres cessent de concorder.

Le vibe coding est très efficace pour générer une intégration fonctionnelle lors d’une démo : se connecter à une API, récupérer des données, mapper quelques champs. Il est en revanche beaucoup moins adapté à la conception de toute l’ingénierie défensive nécessaire pour faire fonctionner une intégration à l’échelle d’une entreprise : Que se passe-t-il lorsque le système source change le nom d’un champ ? Lorsqu’une synchronisation échoue partiellement ? Comment détecter et signaler un flux obsolète avant qu’il ne corrompe les prévisions d’un trimestre ? Comment gérer les limites de requêtes et les nouvelles tentatives sans perdre de données ?

Ce sont les questions que pose quelqu’un qui a déjà vu une intégration échouer en production - pas quelqu’un qui itère sur un prompt jusqu’à obtenir une démo fonctionnelle. Dans l’EPM, le coût d’une erreur de ce type est particulièrement élevé. Une intégration défaillante ne déclenche pas forcément une erreur visible. Elle peut simplement continuer à injecter silencieusement de mauvais chiffres dans un modèle utilisé par un CFO pour prendre des décisions réelles. Une défaillance silencieuse est la pire forme de défaillance. Et c’est précisément celle que le vibe coding est le moins bien équipé pour détecter, car aucun signal visuel ou fonctionnel immédiat n’indique nécessairement que quelque chose ne va pas.

Ce qu’il faut retenir

Rien de tout cela ne constitue un argument contre l'IA dans l'EPM, bien au contraire. L'IA a toute sa place au sein de la plateforme, en s'appuyant sur un modèle gouverné : des agents qui effectuent des analyses d'écarts et rédigent le narratif derrière les chiffres, des interfaces en langage naturel permettant à un planificateur d'interroger une prévision sans écrire de formule, une détection d'anomalies qui signale un flux de données défaillant avant qu'il ne corrompe un trimestre, et des assistants de modélisation qui suggèrent une structure et une logique, avec une validation humaine pour chaque changement. L'argument est plus précis et plus tranché : les propriétés qui rendent une plateforme EPM digne de confiance - exactitude financière rigoureuse, modèle de données multidimensionnel solide, moteur de calcul capable de supporter une charge réelle et simultanée, gouvernance et pistes d'audit intégrées dès le premier jour, et intégrations qui échouent de manière explicite plutôt que silencieuse - sont précisément celles qu'un style de développement rapide, basé sur le ressenti et l'itération d'invites, est structurellement incapable de produire.Rien de tout cela ne constitue un argument contre l’IA dans l’EPM. Bien au contraire.

Le vibe coding optimise la vitesse nécessaire pour arriver à quelque chose qui semble correct. Construire une plateforme EPM exige d’arriver à quelque chose qui est démontrablement correct - et qui le reste, y compris dans des situations que personne n’avait décrites dans le prompt initial. Ce n’est pas un écart que l’on comble avec un meilleur modèle d’IA. On le comble grâce à une ingénierie rigoureuse, volontaire et fondée sur une véritable expertise métier, exactement le type de travail que le vibe coding a été conçu pour contourner.

La même logique s’applique aux agents eux-mêmes. Un agent qui effectue une analyse de variance ou rédige le commentaire expliquant les chiffres hérite de ces cinq mêmes exigences : il doit être parfaitement exact, respecter le modèle de données, fonctionner correctement en cas d’utilisation simultanée, journaliser toutes ses actions et échouer de manière explicite plutôt que silencieus. Partir de zéro revient à reproduire la même erreur que de vibe coder la plateforme qui le sous-tend. Le construire sur une plateforme ayant déjà résolu ces problèmes n’est pas un compromis. C’est la seule approche qui tienne face à un conseil d’administration.