L'IA a fait entrer une idée nouvelle dans les entreprises. Le métier peut désormais construire lui-même l'outil dont il rêve, sans passer par un développeur. La promesse séduit, et elle est en partie vraie.
Nous l'avons vérifié sur nous-mêmes. Notre responsable de gestion, non développeuse, a bâti notre outil de prévisionnel et de trésorerie en dialoguant avec l'IA. Puis nous l'avons industrialisé. Voici où le métier va loin, et où l'ingénierie reprend la main.
Quand le métier code son propre outil
Le besoin était concret : un instrument de pilotage pour établir des prévisionnels, suivre la trésorerie mois par mois et faire varier des hypothèses. Les outils en place ne convenaient pas.
Forekasts, notre outil de prévisionnel, restait difficile à lire pour qui n'était pas déjà spécialiste. Son affichage pouvait induire en erreur, et ses exports arrivaient sans les formules. RCA, l'outil de restitution de notre cabinet comptable, était clair, mais bloqué sur un poste, donc impossible à partager à distance.
Plutôt que de s'en accommoder, la personne qui tient nos comptes a construit l'outil elle-même, en dialoguant avec l'IA. Elle maîtrise la finance, pas le code. Le premier prototype fonctionnel a été prêt en une journée.
Construire par itérations, au plus près du besoin
Le cycle habituel spécifie tout, puis développe. Ici, l'ordre s'inverse : on part d'une idée, on obtient un résultat, on l'évalue, on ajuste, on relance. L'outil se précise à mesure qu'on le voit fonctionner.
Cette bascule a un effet majeur. Elle supprime l'intermédiaire de traduction entre celui qui connaît le métier et celui qui code. Avec lui disparaissent les pertes de contexte et les malentendus.
Le résultat colle au besoin réel, pas au besoin supposé. Beaucoup de réponses obtenues n'auraient pas pu être spécifiées à l'avance. C'est en voyant un résultat concret que la demande se précise.
Des calculs justes, comme exigence non négociable
Un outil de gestion n'a de valeur que si ses chiffres sont exacts. C'est le point où le dialogue avec l'IA a été le plus ferme.
La consigne de cadrage était explicite : ne pas simplifier le logiciel pour se faciliter la tâche, mais garantir des sommes justes, quitte à produire un code plus complexe. La justesse d'abord, la facilité ensuite.
Derrière cette exigence, il y a une conviction. Un outil de pilotage qui arrondit ou approxime en silence est plus dangereux qu'utile. Il oriente des décisions sur des bases fausses.
Le prototype connaît ses limites
Ce prototype faisait le travail. Mais il restait un prototype, et il ne le cachait pas. Tenir cette lucidité compte autant que de le construire.
Ses limites étaient nettes : des données conservées seulement dans le navigateur, aucune authentification, aucun partage réel, tout le code dans un fichier unique, ni journalisation ni plan de reprise, sécurité non traitée.
Un prototype est un laboratoire. Il sert à apprendre et à valider un besoin, pas à être déployé tel quel. Le confondre avec un logiciel de production est l'erreur la plus coûteuse.
Le point remarquable est ailleurs. Le plafond atteint par le métier n'était pas technique. Il tenait aux choix d'architecture, de stockage, de sécurité et de continuité. Précisément là où l'ingénierie reprend toute sa valeur.
L'industrialisation, là où l'ingénierie reprend sa valeur
Reprendre ce prototype ne voulait pas dire tout réécrire. Cela voulait dire le porter dans une architecture pérenne, sans perdre ce qui faisait sa justesse.
Nous avons séparé le back-end, exposé en API, du front réécrit proprement. L'authentification, la structure et la chaîne de déploiement ont été héritées d'un socle existant. Ce socle a fait gagner un temps considérable.
Le cœur restait les règles de gestion. Nous les avons préservées à l'identique, puis prouvé cette fidélité : mêmes saisies dans le prototype d'origine et dans l'application déployée, puis comparaison des résultats. Tant qu'ils coïncident, le portage est fidèle.
C'est la différence entre aller vite et aller vite n'importe comment. La vitesse vient du socle réutilisé et de l'appui de l'IA. La fiabilité vient de la méthode : tests, comparaison, revue.
La stack, en toute transparence
Puisque nous parlons de rigueur, autant décrire les briques. Rien d'exotique : des composants éprouvés, assemblés proprement, plutôt qu'une pile à la mode.
- Un back-end en API-First, qui porte les règles de gestion et la persistance des données.
- Une base de données côté serveur, qui remplace le stockage local du prototype : des données centralisées, partagées et pérennes.
- Un front réécrit, qui reprend l'interface à onglets et les tableaux de synthèse financiers.
- Une authentification et une gestion des accès héritées d'un socle existant, plutôt que réinventées.
- Une chaîne de déploiement déjà prête, qui met l'application en ligne en quelques minutes.
Le choix directeur n'est pas la mode technologique. C'est de garder l'outil maîtrisé, hébergé et réversible, parce qu'il porte désormais nos propres données de gestion.
Encadrer plutôt qu'interdire
Cette histoire pose une question que beaucoup de dirigeants découvrent. Vos équipes métier construisent déjà des outils avec l'IA, parfois sans vous en informer.
L'interdire ne marche pas et prive l'entreprise d'une vraie énergie. Mais un outil né hors des radars devient un risque le jour où il devient central : sécurité non traitée, personne pour le maintenir, aucune sauvegarde.
La réponse tient en un mot : encadrer. Documenter, standardiser, sécuriser, et donner au métier un cadre pour contribuer sans danger. Chez nous, un flux de travail simplifié laisse une personne non technique proposer ses modifications, revues ensuite par un ingénieur.
Le point de vigilance principal n'est pas technique, il est organisationnel : une tâche cadrée, des changements petits et fréquents, une revue toujours possible. Le reste suit.
Ce que le métier fait seul, ce que l'ingénierie rend durable
Ce projet nous a appris une frontière utile. Le métier, outillé par l'IA, va bien plus loin qu'on ne le croit. Il exprime son besoin en le construisant, sans traducteur intermédiaire.
Mais il atteint un plafond, toujours au même endroit : la pérennité. Rendre un outil sûr, partagé, sauvegardé, maintenable et conforme reste un métier d'ingénieur. Ce n'est pas une limite de l'IA, c'est la nature du passage en production.
La vraie question n'est donc pas de savoir s'il faut laisser le métier construire. C'est de savoir à quel moment l'ingénierie doit prendre le relais pour qu'un outil utile devienne un logiciel de confiance.
Nous avons répondu à cette question sur notre propre outil de gestion, avant de la poser à d'autres. C'est un bon test pour n'importe quel partenaire : a-t-il parcouru lui-même le chemin qu'il vous propose ?
Si l'idée vous parle, on peut la déployer chez vous
Nous avons vécu ce trajet, du prototype construit par le métier au logiciel industrialisé, sur notre propre outil. Il se transpose sans peine. Si le sujet vous parle, écrivez-nous : nous en parlerons concrètement, à votre rythme.