Les limites de l'outil interne — et pourquoi elles finissent par coûter cher
Un outil interne atteint ses limites de manière prévisible : il tourne sur le poste d'une seule personne. Quand cette personne est absente, l'outil est inaccessible. Quand un partenaire ou un client demande accès, c'est impossible — ou ça nécessite d'envoyer un fichier lourd que personne ne sait utiliser. Il n'est pas partageable, pas présentable, pas évolutif. Ajouter une fonctionnalité, c'est des jours de bidouillage. Intégrer de l'IA, des notifications, des exports automatiques ? Techniquement hors de portée. Et surtout, il n'est pas monétisable. L'entreprise a créé quelque chose qui a de la valeur — une méthode, un algorithme, une agrégation de données — mais elle ne peut pas la proposer en licence ou en SaaS parce que c'est un fichier. Chez EnerVivo, l'outil d'évaluation ACC était un Excel de 47 onglets. Il fonctionnait. Mais un partenaire a demandé : "Vous pouvez nous donner accès à votre outil ?" Impossible. Ce jour-là, on a décidé d'en faire un vrai produit. Quelques semaines plus tard, acc.enervivo.fr était en ligne.
- Tourne sur un seul poste — inutilisable dès que son propriétaire est indisponible
- Impossible à partager en externe avec des clients ou partenaires sans envoyer un fichier fragile et difficile à prendre en main
- Ajouter une fonctionnalité prend des jours de bidouillage au lieu d'une mise en production propre
- IA, notifications, exports automatiques restent techniquement hors de portée
- La valeur métier qu'il contient — méthode, algorithme, jeu de données — ne peut jamais être vendue en licence ou en service
Deux scénarios d'intervention
Quel que soit le point de départ, la discipline reste la même : préserver ce qui fonctionne déjà, et construire ce qui manque.
Scénario A — Création de A à Z
L'entreprise a un besoin métier identifié mais pas d'outil existant. Conception et développement complet : brief → maquette → développement → tests → mise en production. C'est le cas de l'application ACC : construite de zéro pour répondre au besoin d'évaluation de potentiel d'autoconsommation collective.
Scénario B — Industrialisation d'un outil existant
L'entreprise a déjà un outil qui fonctionne, mais qui a atteint ses limites. Transformation en application web professionnelle, en préservant la logique métier existante : réécriture en application web → interface moderne → déploiement cloud → possibilité de monétisation. Le savoir-faire du client est préservé et valorisé, pas remplacé.
Ce que nous construisons concrètement
Ces trois exemples couvrent des cas d'usage différents (données cartographiques, documents administratifs, calcul technique) mais partagent la même chaîne : récupération de données → traitement → IA → interface → outputs → déploiement.
Application ACC
Cartographie interactive, bases de données certifiées de consommation énergétique, algorithme d'identification des consommateurs, rapport automatique en DOCX. Une chaîne complète : données → traitement → IA → output.
CERFA Automation
Lecture IA de règlements de consultation publique, extraction automatique des informations clés, génération des formulaires DC1/DC2 pré-remplis au format officiel.
Simulateur Batterie
Moteur de calcul pour le dimensionnement et l'analyse de rentabilité des systèmes de stockage. Interface technique, précision métier, résultats exploitables directement.
Ce que l'IA apporte à un logiciel métier
L'IA n'est pas un add-on qu'on plaque sur une application existante. Elle est la plus utile quand elle est intégrée dès la conception, à des étapes précises :
- 01
Lecture de documents
Extraire automatiquement des informations structurées depuis des PDF, des contrats, des formulaires (comme dans CERFA Automation).
- 02
Identification et classification
Retrouver des entités, croiser des bases de données, qualifier des résultats (comme dans l'application ACC).
- 03
Génération d'outputs
Produire des rapports, des synthèses, des documents structurés à partir de données.
Le délai : quelques semaines, pas 12 mois
Le modèle de développement pratiqué est fondé sur des sprints courts avec des livrables fréquents. Le produit avance toutes les 1 à 2 semaines. Si quelque chose ne va pas dans la bonne direction, c'est corrigé immédiatement — pas au bout de 6 mois. Un MVP fonctionnel en quelques semaines est réaliste pour la plupart des projets métier — ce n'est pas une promesse marketing, c'est ce qui a été livré sur les trois applications citées.
Conclusion
Les outils internes (Excel, scripts, bases de données) contiennent de la valeur métier réelle, mais sont limités par leur format. VIVIA transforme ces outils en applications web professionnelles — ou crée des applications de A à Z à partir d'un besoin identifié. L'IA est intégrée nativement : lecture de documents, identification de données, génération d'outputs. Un MVP fonctionnel en quelques semaines — sprints courts, livrables visibles, pas de projet à 12 mois. L'architecture est pensée pour évoluer vers du multi-client et de la monétisation SaaS.
