Bien décrire son besoin à l’IA : ce qui fait la différence

1

La description compte plus que la technologie

Quand une application est assemblée par l’IA, la technique n’est plus l’obstacle. L’IA sait créer un écran, une liste, un formulaire, une règle de calcul. Ce qu’elle ne sait pas, c’est comment votre entreprise travaille. Elle assemble ce qu’elle comprend, et elle comprend ce que vous lui dites.

Demandez « une application pour gérer mes interventions » et vous obtiendrez un écran générique, correct et inutile : une liste d’interventions avec un titre, une date et un statut. Rien sur la façon dont vos techniciens sont affectés, ni sur ce qui se passe quand le client n’est pas là, ni sur qui décide de facturer un déplacement à vide.

Décrivez le résultat que vous attendez, les personnes qui vont utiliser l’application et les contraintes du terrain, et vous obtiendrez autre chose : une application qui suit votre façon de faire. La différence entre les deux ne tient pas à la technologie. Elle tient à la description.

L’IA ne devine pas votre métier. Elle le lit dans ce que vous lui dites.

2

Les cinq éléments d’une bonne description

Une bonne description n’est pas longue. Elle est complète sur cinq points, toujours les mêmes, quel que soit le projet.

1. 01
   Le résultat attendu

   Ce qui doit être vrai à la fin. Par exemple : chaque demande d’intervention reçoit une date planifiée et un technicien dans la journée, et le client en est informé.

2. 02
   Les personnes et leurs rôles

   Qui utilise l’application et pour quoi faire. L’accueil encode, le responsable planifie, le technicien consulte et clôture, la comptabilité facture.

3. 03
   Les objets manipulés

   Les choses concrètes dont on parle : un client, un site, un équipement, un devis, une intervention. Nommez-les comme votre équipe les nomme.

4. 04
   Les règles et les exceptions

   Ce qui se passe normalement, et ce qui se passe quand ça ne se passe pas normalement. Un client absent, une pièce manquante, une intervention hors contrat.

5. 05
   Ce qui exige une validation humaine

   Ce qui ne doit jamais arriver sans qu’une personne l’ait approuvé : envoyer un devis, accorder une remise, clôturer un dossier litigieux.

Si vous savez répondre à ces cinq points, vous avez déjà l’essentiel. Le reste, l’IA le propose.

3

Montrez, ne vous contentez pas d’expliquer

Un document réel en dit plus qu’une page d’explications. Ce que vous utilisez aujourd’hui, même imparfait, contient déjà vos champs, vos étapes et vos habitudes.

• Un devis existant : il montre vos lignes, vos conditions, vos mentions obligatoires.
• Le tableur que vous tenez à la main : ses colonnes sont vos objets, ses onglets sont souvent vos étapes.
• Une capture d’écran de l’outil actuel : ce qui vous manque y est aussi visible que ce qui fonctionne.
• Un exemple de cas difficile : le dossier qui a posé problème le mois dernier vaut dix règles abstraites.

Apportez aussi votre vocabulaire. Si votre équipe dit « dossier », « intervention » ou « bon de commande », dites-le ainsi. L’IA réutilise vos mots dans les écrans, les listes et les messages. Le jour où l’application arrive, votre équipe la reconnaît au lieu de devoir l’apprendre.

4

Demander avant d’assembler

La meilleure description ne s’écrit pas d’un trait. Elle se construit dans une conversation. Avant d’assembler quoi que ce soit, l’IA doit poser ses questions : qui valide ce devis, que se passe-t-il si le client annule, faut-il un historique des modifications. Puis elle propose un plan que vous relisez.

Répondre « je ne sais pas » est une réponse acceptable. Vous n’avez pas à trancher toutes les règles avant de commencer. Une valeur par défaut raisonnable vous est proposée, et vous l’ajustez quand le cas se présente.

Préférez aussi les petites demandes successives à la grande demande unique. Une première version qui gère le cas normal, puis une exception, puis une règle de validation : chaque étape reste lisible et vérifiable. Une demande géante produit une application que personne n’a le temps de relire.

5

La connaissance qui reste attachée au projet

Ce que vous expliquez une fois ne devrait pas être répété à chaque demande. Vos règles, vos rôles, vos formulations préférées, les choses à éviter : tout cela forme la connaissance de votre entreprise, et elle reste attachée au projet.

Concrètement, si vous avez dit qu’aucune remise n’est accordée sans l’accord du gérant, chaque évolution ultérieure respecte cette règle sans que vous ayez à la rappeler. Si vous avez dit que vos clients s’appellent « membres », le mot ne change pas au troisième écran.

Cette connaissance est aussi ce qui permet à l’IA de rester dans son périmètre. Elle voit ce que vous avez autorisé, et rien de plus. Nous avons détaillé ce principe dans Ce qu’un assistant d’IA doit savoir avant d’agir : le contexte autorisé compte davantage qu’une réponse brillante mais isolée.

6

Dans Neoo : décrire, structurer, tester, valider

Chez Neoo, cette conversation se déroule dans Neoo Forge, l’atelier qui assemble vos applications avec l’IA. Vous décrivez votre besoin avec vos mots. Forge le structure en objets, écrans, règles, rôles et parcours, puis vous montre le plan avant d’assembler quoi que ce soit.

Une fois assemblée, l’application est testée : les cas normaux, les exceptions, les permissions de chaque rôle et le retour en arrière. Votre équipe valide avant toute mise en service. Nous décrivons la démarche complète dans Créer une application métier sans coder et la façon de faire évoluer l’application en sécurité dans Modifier, valider, revenir en arrière.

Cette description tient en quelques lignes. Elle suffit à Forge pour proposer un plan, poser les questions qui restent et assembler une première version que vous vérifiez. Découvrez l’atelier sur la page Neoo Forge ou réservez une démonstration pour le voir avec votre propre cas.