Développement d’applications métier
que vos équipes utilisent.

Une application métier est un outil interne construit pour un processus précis de votre entreprise : suivi des interventions, devis, planning, demandes clients, contrôle qualité. Elle remplace les tableurs qui se contredisent et les ressaisies entre logiciels. Chez Bonne Idée, nous la construisons en quatre mois, cadrage compris.

On écrit avec vous le processus tel qu’il se passe vraiment, on coupe ce qui n’y sert pas, on conçoit les écrans, puis on construit l’outil. L’IA s’y ajoute là où elle fait gagner du temps, avec la même méthode qu’une intégration LLM.

Vous obtenez un outil en service, utilisé par vos équipes avec vos vraies données, des droits par rôle, et une documentation qui permet à quelqu’un d’autre de le reprendre.

Vous n’avez ni cahier des charges à rédiger, ni technologie à choisir, ni recrutement à lancer avant de savoir ce qu’il faut construire. Si vous lancez un nouveau produit à vendre plutôt qu’un outil interne, c’est un MVP qu’il vous faut.

Vos équipes se serviront de l’outil tous les jours, pendant des années, et cela décide de la façon de le construire. Un prototype impressionnant qui ne tient pas trois mois ne sort pas de chez nous : ce que nous livrons a un modèle de données pensé, des droits gérés, et peut évoluer sans être refait.

Une application qui fait tout ce que vous aviez imaginé et que vos équipes contournent a coûté quatre mois pour rien. Une application qui fait une seule chose, mais que tout le service ouvre chaque matin, a déjà remplacé le tableur.

Le choix entre code et plateforme se calcule, et nous expliquons plus bas comment nous le tranchons.

La plupart des outils internes qui échouent n’échouent pas à la construction. Ils échouent parce que personne n’avait écrit, avant de commencer, le processus qu’ils devaient servir. On construit alors un logiciel qui reproduit le tableur, avec ses défauts.

Ce que le cadrage écrit

Qui saisit quoi, à quel moment, et à partir de quelle source. Qui valide, et ce qui se passe quand il refuse. Ce qui doit sortir : un devis, un planning, un bon d’intervention, un tableau de bord. Et les exceptions, celles qui ne sont écrites nulle part et que vos équipes gèrent de tête.

Trois choses qu’un bon outil interne démontre vite

• Que la saisie se fait une seule fois. Si une information doit encore être recopiée ailleurs, l’outil a raté sa cible.
• Que le parcours tient debout sans longue formation. Si une équipe a besoin d’une démonstration pour s’en servir, l’outil n’est pas prêt.
• Que l’usage se répète. Le vrai concurrent de l’outil est le tableur qui fonctionne déjà.

Le périmètre écrit, et ce qu’il évite

À la fin du cadrage, vous avez une liste de ce qui sera construit et, surtout, une liste de ce qui ne le sera pas. La seconde protège le projet. Sans elle, chaque semaine apporte une idée nouvelle, chacune raisonnable prise isolément, et l’outil dérive jusqu’à ce que le budget s’épuise avant la mise en service.

Cette liste est datée : ce qui n’entre pas dans le premier lot entre dans le suivant, et ce lot se décide avec les données d’usage du premier.

La question arrive toujours trop tôt. Elle se tranche vite une fois le processus écrit, et elle prend des semaines quand on la pose avant.

Les critères qui décident

• Le volume et la logique. Une plateforme suffit pour des écrans de saisie, des listes filtrées et des droits par rôle. Le code s’impose quand la logique devient complexe, que le volume grimpe ou qu’une contrainte de sécurité l’exige.
• Les logiciels à relier. Comptabilité, CRM, ERP : un outil interne qui ne parle pas aux autres recrée de la ressaisie. Le pôle Conseil mène ces branchements avec l’intégration d’outils métier.
• Qui maintiendra l’outil. Une équipe technique interne, nous, ou un autre prestataire : la réponse change le choix.
• Le support. Un outil manipulé assis devant un écran vit dans un navigateur. Un outil sorti de la poche sur un chantier, avec photo et géolocalisation, vit sur un téléphone.

Les générateurs assistés par IA, et leur place réelle

Ils produisent en quelques heures une interface crédible, et c’est un vrai gain pour montrer une direction. Leur limite apparaît dès qu’il faut faire évoluer ce qui a été généré : le modèle de données est souvent implicite, la logique dispersée, et la reprise coûte plus cher que la construction initiale n’a fait gagner. Nous nous en servons pour explorer vite, rarement comme socle. Nous détaillons ce que chacun sait faire dans notre comparatif Bolt ou Lovable.

Ce qui ne dépend pas de l’outil

Un modèle de données pensé avant la première page, parce que c’est lui qu’on ne peut plus corriger sans tout reprendre. Des droits gérés au niveau de la donnée et non de l’affichage, parce qu’un bouton caché n’est pas une protection. Et une nomenclature tenue, pour que la personne qui reprendra l’outil dans un an comprenne ce qu’elle regarde.

Quand l’outil doit répondre à partir de vos documents, il s’appuie sur un agent IA.

Toute plateforme de développement a un plafond. Le passer sous silence serait commode à la vente et coûteux à l’usage, donc nous le posons dès le cadrage.

Les quatre signaux qui annoncent le plafond

• Les temps d’affichage se dégradent sur les écrans qui manipulent beaucoup de lignes, et l’optimisation ne suffit plus.
• Une exigence de conformité impose une maîtrise de l’hébergement ou du chiffrement que la plateforme ne permet pas.
• Le coût de la plateforme, indexé sur l’usage, devient comparable au coût d’une équipe technique.
• La logique métier devient assez spécifique pour qu’on passe plus de temps à contourner l’outil qu’à s’en servir.

Aucun de ces signaux n’arrive pendant les premiers mois. Ils arrivent avec le succès, et ce plafond devient alors un problème de croissance.

La migration, quand elle se pose

Un outil construit sur une plateforme ne se convertit pas automatiquement en code. Ce qui se transfère, en revanche, est ce qui coûte le plus cher à produire : le modèle de données validé, les parcours éprouvés par de vrais utilisateurs, les règles métier écrites, et la connaissance de ce qui ne sert à rien. Une équipe technique qui démarre avec cela ne construit pas la même chose qu’une équipe qui démarre avec un cahier des charges.

C’est aussi pour cela que le choix se fait au cadrage : quand ces signaux sont prévisibles dès le départ, nous construisons directement en code.

Comment nous limitons la dépendance dès le départ

Les données doivent être exportables dans un format lisible, et nous le vérifions en début de projet et non le jour où la question se pose. La logique métier est documentée en français, en dehors de l’outil, pour qu’elle survive à la plateforme. Et les connexions avec vos autres logiciels passent par des mécanismes standards, ce qui les rend reproductibles ailleurs. Quand ces connexions deviennent nombreuses, elles relèvent d’ailleurs de l’automatisation des processus plus que du produit lui-même.

Un outil interne se mène à deux, et la charge côté client est la variable que personne n’annonce à la signature. Nous préférons l’écrire.

Ce que nous attendons de vous, concrètement

• Une personne qui décide, disponible une à deux heures par semaine, et qui a le mandat de trancher sans remonter la question ailleurs. C’est la condition la plus déterminante du respect du délai.
• L’accès aux personnes qui feront le travail dans l’outil, pas seulement à celles qui le décrivent. Sans elles, l’outil se valide entre nous, ce qui ne valide rien.
• La connaissance du métier, que nous n’avons pas et n’aurons jamais aussi bien que vous. Les règles implicites, les exceptions, les cas particuliers qui ne sont écrits nulle part.
• Les contenus réels quand il y en a : un produit rempli de faux textes se teste mal, parce que les utilisateurs réagissent au fond autant qu’à la forme.

Ce que nous portons

La conception des parcours, la construction, le modèle de données, les droits, la mise en ligne, et la préparation des sessions de test. Nous portons aussi la fonction la plus ingrate du projet, qui consiste à défendre le périmètre écrit : rappeler, chaque fois qu’une idée nouvelle apparaît, qu’elle est peut-être bonne mais qu’elle n’est pas dans le lot en cours.

Le rythme, et pourquoi il est court

Des cycles de quinze jours protègent le projet : un projet qui ne montre rien pendant deux mois n’a aucun moyen de savoir qu’il dérive, et découvre l’écart au moment où il coûte le plus cher à corriger.

Le corollaire est que vous verrez tôt des versions imparfaites. Une version intermédiaire qui n’a pas l’air finie est normale. Ce qui devrait vous inquiéter, c’est un projet qui ne montre rien.

Ce qui fait déraper les projets, dans notre expérience

Trois causes reviennent, et aucune n’est technique. Une décision qui attend une réunion qui n’est jamais planifiée. Un périmètre rouvert sans que le délai soit rouvert avec lui. Et des équipes qu’on n’arrive jamais à mobiliser pour essayer, si bien que l’outil se juge sur des avis de direction. Nous signalons ces trois situations dès qu’elles apparaissent, plutôt que de les absorber en silence jusqu’à la livraison.

Comparer deux devis de première version n’a aucun sens tant qu’on ne sait pas ce que chacun inclut. Voici notre découpage, pour que la comparaison soit possible.

Ce qui est toujours compris

• Le cadrage de deux semaines, c’est-à-dire l’écriture du processus à outiller et du périmètre qui l’accompagne.
• La conception des parcours et des écrans, qui est le vrai poste de travail.
• La construction, le modèle de données et la gestion des droits.
• La mise en ligne, puis la prise en main par votre équipe et la documentation qui va avec.

Ce qui se chiffre à part, et pourquoi

Les abonnements aux plateformes, parce qu’ils sont à votre nom et dépendent de votre volume d’usage. La reprise des données anciennes, parce que sa charge dépend de leur état. Les connexions à vos outils de gestion, parce qu’une intégration au CRM est un projet en soi.

Nous les chiffrons séparément pour que vous voyiez chaque arbitrage. Le projet lui-même est chiffré sur mesure, après un premier échange.

Après la mise en service

Après la mise en ligne, la suite se décide sur les données d’usage : un nouveau lot chiffré, ou l’offre Partenaire si les demandes deviennent continues.

Une application métier centralise des données que vos équipes recopiaient d’un tableur à l’autre : elles sont mieux protégées une fois au même endroit, avec des droits gérés au niveau de la donnée. Un accord de sous-traitance des données (DPA) est signé avec le contrat, l’hébergement est en France par défaut, ou sur votre infrastructure quand la sensibilité des données l’exige, et quand l’outil intègre de l’IA, aucun modèle n’est entraîné sur vos données.

Le RGPD, l’AI Act et la relecture humaine sont détaillés sur notre page garanties IA et souveraineté des données.