Comment bien décrire son projet à l’IA pour obtenir l’application voulue ?

Deux personnes peuvent utiliser le même outil d’IA et obtenir des applications très différentes. La raison est rarement l’outil : c’est la description de départ. L’IA ne devine pas ce que vous avez en tête. Elle comble les vides avec des choix par défaut, parfois bons, parfois coûteux à défaire.

Dans cet article, nous vous proposons une méthode simple pour écrire une description qui donne une première version solide, avec un exemple complet à adapter, puis les bonnes habitudes pour faire évoluer l’application sans que l’IA tourne en rond.

Pourquoi la description de départ compte autant

Quand vous écrivez « crée-moi une application de réservation », l’IA doit tout inventer : qui réserve, quoi, avec quelles contraintes, qui valide, ce qui se passe en cas d’annulation. Elle produit alors une application générique, qui ressemble à des milliers d’autres, et vous passez ensuite des heures à la corriger message après message.

À l’inverse, une description précise donne un cadre à l’IA. Elle choisit une organisation des données adaptée, crée les bons écrans dès le départ et anticipe les cas particuliers. Les corrections deviennent des ajustements, et non des reconstructions. Sur les outils qui fonctionnent avec des crédits, la différence se voit aussi sur la facture.

Les six éléments d’une bonne description

Une description efficace tient souvent en une page. Elle répond à six questions, de préférence dans cet ordre.

1. Le problème à résoudre

Commencez par la phrase de mission présentée dans notre premier article : « Mon application permet à [qui] de [faire quoi] sans [quelle difficulté actuelle]. » Elle donne à l’IA le sens du projet, et vous servira ensuite de boussole pour écarter les fonctionnalités inutiles.

2. Les utilisateurs et leurs droits

Listez les types d’utilisateurs : un administrateur, un commercial, un client, un sous-traitant… Pour chacun, précisez ce qu’il peut voir, créer, modifier ou supprimer. Ce point est le plus souvent oublié, et c’est pourtant lui qui détermine la sécurité de l’application : sans consigne, l’IA a tendance à laisser chacun accéder à tout.

3. Le parcours principal

Racontez, étape par étape, ce que fait votre utilisateur le plus important lors d’une utilisation typique. Par exemple : « Le commercial se connecte, choisit un client, ajoute des prestations depuis le catalogue, ajuste les quantités, puis génère un devis en PDF qu’il envoie par e-mail. » Ce récit vaut mieux qu’une longue liste de fonctionnalités.

4. Les écrans

Nommez les écrans principaux et ce qu’ils contiennent : une page de connexion, un tableau de bord, une liste de devis, une fiche client. Si vous avez un croquis, même dessiné à la main, la plupart des outils acceptent une image : c’est souvent plus clair que des mots.

5. Les informations à enregistrer

Listez ce que l’application doit retenir : pour un client, son nom, son adresse et son e-mail ; pour un devis, sa date, son montant et son statut. Inutile de parler de base de données : décrivez simplement ce que vous voulez retrouver plus tard. Signalez aussi les données sensibles, comme des données de santé ou bancaires, qui imposent des règles particulières.

6. Les règles métier et les limites

Ce sont les règles propres à votre activité : un devis expire au bout de 30 jours, une remise de plus de 15 % doit être validée par un responsable, un rendez-vous ne peut pas être pris moins de 24 heures à l’avance. Précisez aussi ce que la première version ne fera pas : c’est aussi utile que ce qu’elle fera.

Un exemple complet à adapter

Voici une description que vous pouvez reprendre comme modèle. Elle concerne un outil de suivi des interventions pour une entreprise de maintenance :

« Je veux créer une application web qui permet à mes techniciens de suivre leurs interventions chez nos clients, sans passer par des fichiers Excel partagés.

Il y a trois types d’utilisateurs : l’administrateur, qui gère les comptes, les clients et le planning ; les techniciens, qui voient uniquement leurs propres interventions ; les clients, qui consultent l’historique des interventions sur leurs sites, et rien d’autre.

Parcours principal : le technicien se connecte depuis son téléphone, voit ses interventions du jour, ouvre une intervention, indique son heure d’arrivée, décrit le travail réalisé, ajoute des photos, fait signer le client à l’écran, puis clôture l’intervention. Le client reçoit alors un compte rendu par e-mail.

Écrans : connexion, planning du jour, fiche intervention, historique par client, administration des comptes.

Informations à enregistrer : les clients (nom, adresse des sites, contact) et les interventions (date, site, technicien, statut, description, photos, signature).

Règles : une intervention clôturée ne peut plus être modifiée par le technicien ; seul l’administrateur peut la rouvrir.

La première version ne gère ni la facturation, ni le stock de pièces. L’interface est en français et doit être utilisable sur téléphone. »

Pourquoi cet exemple fonctionne

Chaque paragraphe répond à l’une des six questions. Les droits d’accès sont explicites : l’IA sait que les techniciens ne voient que leurs interventions, et les clients que leurs sites. Le parcours raconte une vraie journée de travail. Enfin, la dernière phrase fixe des limites claires, ce qui évite que l’IA ajoute d’elle-même un module de facturation que personne n’a demandé.

Construire étape par étape

Même avec une excellente description, ne demandez pas tout d’un coup. Les outils d’IA travaillent mieux sur des demandes ciblées. Une bonne façon de procéder :

1. demandez d’abord la structure : les écrans, la navigation et la connexion, sans logique complexe ;

2. ajoutez ensuite le parcours principal, et testez-le de bout en bout ;

3. vérifiez les droits d’accès avec deux comptes différents, avant d’aller plus loin ;

4. ajoutez les fonctionnalités secondaires une par une, en testant après chacune ;

5. terminez par les finitions : textes, couleurs, messages d’erreur.

Après chaque étape qui fonctionne, sauvegardez votre travail. La plupart des outils permettent de revenir à une version précédente, et la synchronisation avec GitHub vous protège si quelque chose tourne mal, comme nous l’expliquions dans notre comparatif des outils.

Bien formuler une demande de modification

Une fois la première version en place, la qualité de vos demandes compte autant que la description de départ. Trois principes simples suffisent.

Une demande, un sujet

Évitez les messages qui mélangent cinq changements. Si l’un d’eux casse quelque chose, il devient difficile de savoir lequel. Une demande ciblée est plus facile à vérifier, et plus facile à annuler.

Le résultat attendu, pas la solution

Plutôt que « ajoute une colonne cachée dans la table », écrivez « quand un devis est accepté, je veux voir la date d’acceptation sur sa fiche ». L’IA choisit souvent une meilleure solution technique quand elle comprend le besoin.

Le contexte d’un problème

Quand quelque chose ne marche pas, décrivez ce que vous avez fait, ce que vous attendiez et ce qui s’est passé à la place. Si un message d’erreur s’affiche, copiez-le tel quel. Une capture d’écran aide aussi beaucoup.

Les erreurs qui font tourner l’IA en rond

Certaines habitudes coûtent cher en temps et en crédits :

• décrire la technique au lieu de l’usage, avec des termes que l’on ne maîtrise pas ;
• oublier les droits d’accès, et découvrir plus tard que chaque utilisateur voit les données des autres ;
• changer d’avis sur l’organisation des données en cours de route, ce qui oblige l’IA à tout réorganiser ;
• accepter une fonctionnalité sans la tester, puis en empiler d’autres par-dessus ;
• coller des clés secrètes ou des mots de passe dans la conversation, alors qu’ils doivent être rangés dans l’espace prévu par l’outil (voir notre article sur les clés API).

Aucune de ces erreurs n’est grave si elle est repérée tôt. Elles deviennent coûteuses quand l’application accueille de vrais utilisateurs, et c’est souvent là qu’un regard technique fait gagner le plus de temps.

En résumé

Une bonne description répond à six questions : le problème, les utilisateurs et leurs droits, le parcours principal, les écrans, les informations à enregistrer et les règles métier. Elle tient en une page et vous fait gagner des jours. Ensuite, avancez étape par étape, une demande à la fois, en testant et en sauvegardant chaque version qui fonctionne. Dans le prochain article, nous verrons ce que l’IA a réellement construit derrière votre application : base de données, hébergement et API.