Créer un logiciel métier avec l’IA : les pièges à éviter

De la première démo au travail quotidien : douze points de contrôle, un atelier fictif et des exemples pour vérifier calculs, données, accès, budget et reprise.

Un fichier clients s’ouvre, un devis se prépare : votre logiciel métier créé avec l’IA prend forme. Ce qui compte le lundi matin se voit moins : le bon montant, le bon destinataire, une information conservée et la possibilité de continuer après une panne.

Ce guide suit un cas fictif : l’atelier de Camille, une petite entreprise qui veut remplacer son tableau de suivi des devis. Camille prépare les offres ; Sam organise les interventions. Ils souhaitent retrouver les clients, suivre les réponses et éviter de recopier les mêmes informations. Ce ne sont ni des clients de Maestro ni un projet réellement testé.

Chaque piège débouche sur une vérification concrète. Vous pouvez poser ces questions sans savoir programmer. Certaines réponses demandent une personne technique, notamment avant d’utiliser de vraies données clients ou d’ouvrir l’application à plusieurs personnes.

1. Construire à partir d’une demande trop vague

« Je veux gérer mes devis » laisse beaucoup de décisions ouvertes. Faut-il seulement retrouver un document ? Calculer son montant ? L’envoyer ? Suivre une acceptation ? L’IA peut proposer un ensemble cohérent en apparence qui ne correspond pas à votre manière de travailler. Le premier signal est simple : chacun décrit différemment ce que l’application doit faire.

Camille précise son besoin : à la fin de la journée, elle veut voir les offres envoyées depuis plus d’une semaine et décider lesquelles relancer. Elle n’a pas besoin, dans cette première version, de produire des factures ou de prendre des paiements. Cette frontière limite la première version à une fonction complète.

Écrivez le déroulement actuel avec un exemple inventé : un client demande une prestation, Camille prépare une offre, le client répond, Sam reçoit la date prévue. Notez où l’information arrive, qui la modifie et ce qui prouve que l’étape est terminée. Incluez une exception, comme une offre annulée.

Faites relire ce texte par la personne qui effectuera l’action. Si Sam comprend autre chose, corrigez le document avant l’écran. Le cahier des charges non technique aide à rassembler ces règles sans transformer votre projet en dossier interminable.

2. Prendre une démonstration pour une application prête

Une démonstration montre un parcours choisi. Elle peut utiliser des exemples préremplis, simuler un envoi ou conserver les informations uniquement le temps de la visite. Ce n’est pas forcément un défaut : elle sert à discuter d’une idée. Le problème commence quand on lui confie du travail sans connaître ce qui fonctionne réellement.

Camille crée une offre et voit une confirmation. Elle ferme l’application, la rouvre, puis cherche son document. Ce petit parcours apporte une information que la beauté de l’écran ne donnait pas : la saisie est-elle encore présente ? Elle compare aussi les données de l’offre enregistrée avec celles qu’elle vient de saisir.

Essayer le parcours entier

• Créer un client fictif et une offre qui lui appartient.
• Fermer puis rouvrir l’application et retrouver les deux.
• Modifier une information, enregistrer et vérifier le document produit.
• Annuler une offre et observer les listes dans lesquelles elle apparaît.

Demandez à la personne qui construit l’outil de distinguer ce qui est opérationnel, simulé et encore absent. Conservez cette réponse dans le projet. Un message « envoyé » doit correspondre à un résultat que vous pouvez constater avec une adresse de test que vous contrôlez. Sinon, l’envoi reste à vérifier et ne doit pas servir à une relance réelle.

3. Croire un résultat annoncé sans examiner la preuve

Une IA peut annoncer que tout fonctionne après avoir vérifié une partie seulement du parcours. Un test automatique peut aussi reprendre la même mauvaise règle que le programme. Si les deux appliquent une remise à la livraison alors que vous vouliez l’exclure, le voyant vert ne répond pas à votre besoin.

Dans notre exemple fictif, la prestation coûte 200 €, la livraison 30 € et la remise de 10 % concerne uniquement la prestation. Hors taxes, le montant attendu est donc 210 € : 180 € de prestation et 30 € de livraison. C’est un exemple de calcul, pas un modèle de devis fiscal ou comptable.

Écrivez ce résultat avant de demander la modification. Comparez ensuite le montant à l’écran, le montant enregistré et le document destiné au client. Ajoutez une offre sans remise et une offre sans livraison. Vous comparez ainsi plusieurs situations à un résultat connu.

Demandez aussi les contrôles non réalisés. Une limite écrite aide à décider ; une certitude vague n’aide pas. Le guide sur les tests avant le code explique comment conserver ces exemples pour les réutiliser lors des modifications suivantes.

4. Confondre connexion et protection des dossiers

Un écran de connexion ne suffit pas à expliquer qui peut consulter ou modifier quoi. Dans l’atelier, Sam a besoin du planning et des coordonnées utiles à l’intervention. Camille peut vouloir réserver certaines informations commerciales à une autre fonction. Il faut exprimer cette répartition avant de demander simplement « des comptes utilisateurs ».

Préparez des comptes et des dossiers fictifs dans un environnement de test autorisé. Écrivez, pour chaque rôle, les informations visibles et les actions permises. Demandez à la personne technique de vérifier cette liste, y compris quand une action devrait être refusée. Ne faites pas ces essais sur les comptes de clients réels.

L’OWASP recommande de limiter les autorisations au nécessaire et de contrôler chaque demande du côté qui protège les données. Masquer un bouton ne remplace pas ce contrôle.

Pour Camille, la question à transmettre devient précise : « Avec un compte de test destiné aux interventions, peut-on consulter les rendez-vous autorisés sans accéder aux informations commerciales réservées ? Peux-tu documenter la vérification ? » Sans réponse, reportez l’ajout de vrais dossiers.

Prévoyez également le départ d’une personne : qui retire son accès et qui le vérifie ? Gardez le propriétaire du compte d’administration identifié. Si tout repose sur une adresse appartenant à un prestataire absent, vous avez découvert une dépendance à régler avant le lancement.

5. Supposer que « local » signifie « aucune donnée ne sort »

L’endroit où le projet est conservé, celui où l’IA traite une demande et celui où l’application finale stocke ses données sont trois questions différentes. Un outil installé sur votre ordinateur peut contacter un fournisseur d’IA. L’application qu’il aide à construire peut, elle aussi, utiliser des services distants.

Camille n’a pas besoin de transmettre son vrai fichier clients pour expliquer la forme d’un devis. Elle prépare des noms, adresses et montants inventés. Elle conserve toutefois les difficultés du quotidien : deux personnes portant le même nom, un champ vide, une offre annulée. Le jeu d’essai reste utile sans reproduire ses dossiers.

La CNIL invite à choisir l’IA selon l’usage et les données transmises. Avant un envoi réel, faites vérifier les conditions du fournisseur et les règles de votre activité par une personne compétente.

Demandez une explication lisible : quels fichiers l’assistant peut-il lire, quels éléments peuvent être transmis, à quel fournisseur et avec quels réglages ? Une capture destinée à demander de l’aide peut déjà contenir un nom ou une adresse. Vérifiez aussi ce que vous joignez à une conversation.

Ne collez pas de mot de passe ou de clé d’accès dans le cahier des charges. Demandez à la personne technique de préparer leur stockage et leur remplacement. Si un secret a été partagé par erreur, faites révoquer et remplacer la clé ou changer le mot de passe concerné. Effacer le message seul ne retire pas un accès déjà obtenu.

6. Ajouter une fonction sans revérifier les anciennes

Une modification peut toucher plusieurs endroits : la saisie, le calcul, le document et les listes de suivi. Le symptôme classique est une fonction qui marche enfin, accompagnée d’une autre qui ne marche plus. On le découvre tard si personne ne refait le parcours habituel après le changement.

Camille demande une remise sur les prestations. Elle précise aussi que les frais de livraison restent inchangés, que l’offre sans remise conserve son total et que le statut d’acceptation ne bouge pas. Ces points décrivent ce qui doit rester vrai autour de la nouveauté, au lieu de laisser l’assistant le deviner.

Une fiche de modification courte

• Changement demandé : une remise sur les prestations.
• Règles conservées : livraison, anciens montants et statuts.
• Exemples à refaire : offre standard, offre remisée, offre annulée.
• Décision : accepter la version ou demander une correction précise.

Avant l’intervention, demandez un état du projet que l’on peut retrouver. Après l’intervention, faites les vérifications sur une copie de travail. Le guide des corrections qui cassent autre chose détaille cette habitude. Si revenir en arrière implique les données saisies depuis, faites expliquer leur traitement : récupérer une ancienne version du code ne récupère pas automatiquement le travail effectué entre-temps.

7. Budgéter la création et oublier l’exploitation

L’abonnement ne représente pas forcément le coût complet. L’atelier devra peut-être payer l’IA, un hébergement, des envois de messages ou une intervention de maintenance. Le temps que Camille consacre à vérifier les règles et corriger les données fait aussi partie de l’effort réel.

Séparez les dépenses de construction des dépenses nécessaires pour continuer à travailler. Une application peut coûter peu pendant une démonstration, puis davantage lorsque les utilisateurs, les documents ou les appels à un service augmentent. Évitez d’extrapoler le prix d’un essai court à toute une année sans préciser les hypothèses.

• Construction : cadrage, essais d’IA, reprises, vérifications et aide technique.
• Fonctionnement : services utilisés, stockage, sauvegarde et assistance.
• Évolution : nouvelles demandes, adaptation aux services externes et contrôles après modification.

Camille fixe un point d’arrêt avant chaque nouveau lot de travail. Elle note la dépense observée pendant l’essai, ce qui a été obtenu et ce qui reste à payer. Une limite de budget écrite permet de choisir entre poursuivre, réduire la demande ou demander un avis ; elle ne constitue pas un plafond technique chez le fournisseur.

Vérifiez séparément les alertes, les limites réellement bloquantes et les conditions de facturation du service choisi. Le guide du budget d’une application aide à préparer cette discussion.

8. Avoir les fichiers sans savoir ce qu’on peut reprendre

La propriété du code, les droits sur les éléments utilisés et la capacité à remettre l’application en route méritent des réponses séparées. Posséder un dossier de fichiers ne vous dit pas, à lui seul, quels comptes sont nécessaires ni quelles conditions accompagnent une bibliothèque, une image ou un service.

Demandez un inventaire du projet : code, documents, composants ajoutés, services et accès nécessaires. Pour chaque élément tiers, conservez sa provenance et les informations de licence disponibles. Faites examiner les conditions incertaines par une personne compétente avant une utilisation commerciale ; ce guide ne tranche pas les droits attachés à votre projet.

Camille demande ensuite un passage de relais concret : « Si une autre personne reprend l’outil, que dois-je lui remettre pour qu’elle puisse le démarrer avec des données d’essai ? » La réponse attendue décrit des fichiers et des étapes. « Tout vous appartient » ne remplace pas cette préparation pratique.

Le guide de propriété et de reprise du code approfondit cette distinction. Faites garder les comptes importants sous le contrôle de l’entreprise et documenter la personne qui peut les administrer. L’objectif est de rendre une reprise possible sans dépendre du souvenir d’une longue conversation avec un assistant ou un prestataire.

9. Découvrir trop tard que la sortie n’a pas été préparée

Un export et une sauvegarde répondent à des besoins différents. L’export aide à relire ou déplacer des informations. La sauvegarde doit permettre de retrouver un état utilisable avec les éléments nécessaires. Un fichier téléchargé peut manquer de pièces jointes, de liens entre dossiers ou de réglages.

Dans l’exemple de Camille, on prépare trois clients fictifs, leurs offres et quelques documents joints. La personne technique réalise un export, puis explique comment chaque offre retrouve son client. Une simple liste de noms ne suffit pas si les montants et l’historique d’acceptation disparaissent au passage.

L’ANSSI recommande de préparer la restauration et de l’essayer régulièrement. Elle rappelle également d’inclure les éléments permettant de réinstaller et configurer les applications. La présence d’une sauvegarde ne prouve donc pas, à elle seule, une reprise réussie.

Demandez un essai séparé de l’outil utilisé au quotidien : remettre une copie en fonctionnement, retrouver les dossiers attendus et noter ce qui manque. Camille vérifie le contenu métier ; une personne technique organise l’opération sans écraser les données de travail. Le résultat et les étapes restent écrits.

Fixez enfin la perte de travail et la durée d’interruption acceptables pour votre activité. Une journée de saisie perdue peut être supportable dans un essai, beaucoup moins après le démarrage. Si vous remplacez un outil existant, préparez le passage des données Excel avant de retirer l’ancien accès.

10. Promettre un usage en équipe sans organiser le partage

Faire fonctionner une application sur un ordinateur ne montre pas comment deux personnes travailleront ensemble. Elles peuvent utiliser des copies différentes, écraser une modification ou ne pas voir le même statut. Il faut choisir où se trouve l’information commune et comment chacun y accède, avec l’aide de la personne qui conçoit l’outil.

Camille et Sam ouvrent une offre fictive. Camille change la date prévue pendant que Sam met à jour le contact. Quelle information doit être conservée ? Comment sait-on qu’une autre personne a modifié le dossier ? L’expression « application collaborative » ne répond pas à ces questions.

Demandez aussi ce qui se passe sans connexion et lors du retour du réseau, si cet usage est prévu. La saisie attendra peut-être la reconnexion. Ce choix doit être compris des utilisateurs et correspondre au travail réel.

Une application locale ne supprime pas ces décisions, et elle ne prouve pas que Maestro propose une collaboration entre utilisateurs sans serveur. Distinguez toujours les capacités de l’outil de construction de celles de votre future application. Faites documenter le partage, les comptes et le traitement des modifications simultanées avant de choisir la solution.

11. Lancer sans responsable pour la suite

Le premier jour d’utilisation marque le début de nouvelles questions : qui reçoit les erreurs, qui décide qu’un problème bloque le travail et qui peut corriger l’application ? Sans responsable disponible, une difficulté ordinaire peut immobiliser l’atelier.

Commencez par un périmètre que vous pouvez observer. Camille essaie le suivi des relances avec des données fictives, puis organise un usage limité une fois les vérifications appropriées effectuées. L’outil de référence est clairement désigné à chaque étape, pour éviter que deux listes contradictoires servent en même temps.

Préparez une consigne de secours compréhensible : à qui signaler l’erreur, quelles informations noter sans exposer de données confidentielles et comment poursuivre le travail autorisé. Planifiez également les mises à jour des composants avec la personne technique. Une application terminée n’est pas un objet que l’on peut nécessairement oublier pendant des années.

Les traitements sensibles, les paiements et les activités réglementées demandent un accompagnement adapté à leurs enjeux. Choisir une petite première version aide à apprendre ; cela ne réduit pas automatiquement les conséquences d’une erreur sur les données qu’elle traite.

12. Garder une fiche de décision avant de poursuivre

Pour votre propre projet, recopiez les lignes suivantes et remplissez-les avec une personne qui connaît le métier. Remplacez « c’est bon » par un résultat observable, une date ou une inconnue à résoudre.

• Usage prioritaire : quelle action doit devenir plus simple, pour qui ?
• Règle essentielle : quel résultat avons-nous calculé ou défini à l’avance ?
• Preuve : quel parcours complet avons-nous réellement essayé ?
• Données et accès : qu’avons-nous vérifié, et qui traite les inconnues ?
• Dépenses : quel montant ou événement déclenche une nouvelle décision ?
• Reprise : quand une copie a-t-elle été restaurée et avec quel résultat ?
• Suite : qui reçoit les incidents et qui autorise la mise en service ?

Dans l’atelier fictif, un écran réussi suffit pour continuer à discuter du besoin. Il ne suffit pas pour envoyer des offres réelles. Chaque preuve ajoute une raison précise d’avancer ; chaque inconnue importante indique un travail à terminer. Vous pouvez demander cette façon de rendre compte à un assistant comme à un prestataire.

Maestro rassemble le cadrage, la construction et les validations du projet. Sa beta est proposée sur invitation sur Mac, gratuitement pour l’application, avec l’usage IA en plus. Consultez la présentation de Maestro pour les conditions actuelles. Ce cadre aide à organiser les échanges ; la décision d’utiliser votre logiciel repose sur les vérifications adaptées à votre activité.

Revenir au sommaire