Créer un outil interne avec l’IA sans coder est réaliste si vous partez d’un problème étroit, de règles métier explicites et d’un test fait par la personne qui connaît le travail. L’IA peut construire l’interface et le code d’un calculateur ou d’un suivi de demandes. Elle ne sait pas, seule, décider quelle règle de remise est applicable, quel champ doit rester confidentiel ou quel résultat est acceptable.
Le bon premier projet n’est donc pas « notre logiciel métier ». C’est une petite situation qui revient chaque semaine : vérifier l’éligibilité d’une demande, calculer un reste à traiter, ou suivre les demandes internes sans chercher dans plusieurs boîtes mail. Cet article montre une méthode concrète, avec un exemple de calculateur, pour passer d’un besoin à un prototype testable.
En bref
- Un bon premier outil interne traite une décision ou une saisie, pas tout un processus.
- Le métier fournit les règles et les cas de test ; l’agent aide à construire et modifier le prototype.
- Le résultat utile est un outil accompagné de ses règles, de ses tests et de ses limites connues.
- Les données réelles, les droits d’accès et la maintenance déterminent le moment où une revue technique devient nécessaire.
Choisir un outil interne à la bonne taille
Un outil est à la bonne taille quand son utilisateur, son entrée et son résultat tiennent en une phrase. Par exemple : « le responsable exploitation saisit quatre éléments d’une demande et obtient une priorité à vérifier avant répartition ». Cette phrase évite que le prototype parte vers un logiciel de gestion complet.
Les candidats les plus simples ont trois caractéristiques : la tâche est récurrente, les informations nécessaires sont déjà connues et les règles peuvent être relues par le métier. Un calculateur d’éligibilité, un formulaire de suivi, un générateur de compte rendu à partir de champs validés ou une liste de contrôle de dossier sont de bons points de départ.
| Bon premier périmètre | Pourquoi il se teste | À repousser |
|---|---|---|
| Calculateur interne | Entrées et résultat attendus sont comparables à la main. | Moteur de prix qui engage automatiquement l’entreprise. |
| Suivi de demandes | Quelques statuts, un responsable et une date suffisent au départ. | Remplacer un CRM ou un outil de ticketing entier. |
| Contrôle de complétude | La liste des pièces et exceptions peut être validée ensemble. | Prendre seul une décision RH, financière ou juridique. |
Avant d’ouvrir un agent de code, notez quatre éléments : l’utilisateur, l’action qu’il doit accomplir, les données nécessaires et le résultat attendu. Ajoutez ensuite ce que l’outil ne doit pas faire. Ce dernier point est une protection contre les ajouts séduisants mais hors périmètre.
Exemple : un calculateur de priorité de demandes
Prenons le cas d’une PME qui reçoit des demandes internes par mail : demande de devis, question logistique, incident matériel. Le responsable veut une vue simple pour les trier, sans prétendre remplacer les outils de support existants.
Le prototype peut demander quatre informations : type de demande, date promise, activité bloquée ou non, et niveau de client concerné. Il affiche une priorité proposée : à traiter aujourd’hui, cette semaine, ou à planifier, puis laisse à l’utilisateur le dernier mot. La règle doit être formulée en français avant d’être confiée à l’agent :
Règles à valider avant de construire
- Une demande qui bloque une activité est prioritaire, quelle que soit sa date promise.
- Une demande attendue aujourd’hui est prioritaire sauf si les informations sont incomplètes.
- Une demande incomplète reste visible, avec un statut « à compléter », et ne doit pas être classée comme résolue.
- L’outil propose une priorité ; il ne l’envoie pas automatiquement à un tiers.
Cette formulation produit un brief plus utile qu’un prompt du type « fais-moi un outil de suivi moderne ». L’agent peut ensuite proposer une petite interface, mais les règles restent la référence. Un agent comme Claude Code peut lire un dossier, modifier des fichiers et lancer des commandes ; la documentation officielle de Claude Code décrit ce mode de travail sur un projet local. Cela n’enlève pas la nécessité de relire chaque comportement métier.
Construire par petites itérations vérifiables
Demandez d’abord un écran sans connexion, sans données réelles et sans automatisation d’envoi. Le premier objectif est de vérifier les champs, les libellés et le résultat. Ensuite seulement, ajoutez une règle à la fois. Un changement petit est plus facile à expliquer, annuler et tester.
- Écran statique : afficher les quatre champs et les trois niveaux de priorité.
- Première règle : faire remonter une activité bloquée en priorité haute.
- Cas incomplet : bloquer le calcul ou afficher clairement ce qui manque.
- Historique minimal : conserver, si c’est nécessaire, la date, le statut et la personne qui a ajusté la priorité.
- Export ou partage : ne l’ajouter qu’après validation du fonctionnement local.
À chaque étape, demandez à l’agent d’expliquer les fichiers modifiés et de fournir le cas testé. Conservez les instructions et les changements dans un dossier partagé ou un dépôt Git. Cette trace sert quand un collègue doit comprendre l’outil, et évite de dépendre de la mémoire d’une seule personne.
Tester les résultats, pas seulement l’interface
Un bouton qui répond ne prouve pas qu’un outil est juste. Pour ce calculateur, préparez une feuille de test avant la construction : des demandes qui devraient être prioritaires, d’autres à planifier, et des entrées volontairement incomplètes. Comparez la priorité affichée avec la décision attendue.
| Cas de test | Résultat attendu | Ce que cela vérifie |
|---|---|---|
| Activité bloquée, échéance dans une semaine | À traiter aujourd’hui | La règle de blocage prime sur la date. |
| Échéance aujourd’hui, informations complètes | À traiter aujourd’hui | La date est correctement prise en compte. |
| Échéance aujourd’hui, champ obligatoire absent | À compléter | L’outil ne transforme pas une donnée manquante en décision. |
Faites aussi tester une personne qui n’a pas participé à la construction. Elle repérera les libellés ambigus et les gestes qui semblent évidents seulement à l’auteur. Si l’outil commence à stocker des informations nominatives ou confidentielles, impliquez la DSI et le référent données. Les contrôles d’accès doivent être pensés par ressource et par action, avec des droits minimaux et vérifiés à chaque requête, comme le rappelle le guide officiel OWASP sur l’autorisation.
Livrer, partager et savoir s’arrêter
Un prototype utilisable par une petite équipe a besoin d’un propriétaire nommé. Cette personne recueille les corrections, garde la liste des règles et décide si une demande est un ajustement ou un changement de périmètre. Sans cette responsabilité, les demandes s’empilent et l’outil devient vite difficile à comprendre.
Le paquet de livraison peut tenir sur une page : objectif, utilisateur visé, données utilisées, règles, tests réussis, limites et contact de reprise. Ajoutez la liste des éléments à ne jamais y déposer. Si une fonction touche un dossier client, des données de salariés, des accès à un logiciel métier ou une décision sensible, le prototype doit sortir du cadre de l’atelier et être revu techniquement.
Pour aller plus loin
Une équipe métier peut apprendre cette méthode sur son propre cas, depuis la spécification courte jusqu’aux tests et aux limites de diffusion. Cette progression est au cœur de la formation vibe coding pour les profils non développeurs.
Quand l’outil a prouvé sa valeur et doit être déployé plus largement, l’enjeu change : tests, sécurité, exploitation et maintenance deviennent un projet à part entière. Notre article sur le passage d’un prototype IA en production explique ce qui doit alors être repris.
