Dialoguer avec une IA : prompts, méthodes et construction d’un échange
Dans « Comprendre les IA conversationnelles : dialogue, apprentissage et illusion de compréhension », nous nous sommes intéressés à la nature particulière de ces échanges et aux mécanismes qui peuvent nous donner l’impression de dialoguer avec un interlocuteur qui comprend, raisonne ou se souvient comme nous.
Dans ce nouveau volet, nous allons déplacer le regard vers la pratique : comment formuler une demande, construire un échange et faire évoluer une conversation avec une IA pour qu’elle reste réellement utile ?
Il ne s’agit pas de proposer une collection de prompts prêts à l’emploi ni de chercher une formule idéale. Nous verrons au contraire que la qualité d’un échange dépend souvent moins d’une phrase parfaitement construite que du contexte fourni, des précisions apportées et de notre capacité à reformuler, vérifier ou recentrer progressivement la conversation.
Une IA conversationnelle ne se limite alors plus à produire une réponse. Elle peut participer à l’exploration d’un problème, aider à confronter des hypothèses ou accompagner la construction progressive d’une solution. L’enjeu reste toutefois de conserver la maîtrise de cette conversation et de ne pas confondre la fluidité de l’échange avec la pertinence de ce qui est produit.
Le prompt n’est qu’un point de départ
Lorsque nous découvrons les intelligences artificielles génératives, il est difficile d’échapper à une promesse qui revient régulièrement : celle du prompt parfait. Sur les réseaux sociaux, dans les vidéos ou dans certains guides, des formulations sont parfois présentées comme des recettes capables de produire presque automatiquement de meilleurs résultats.
Cette idée est séduisante. Elle laisse penser qu’il suffirait de trouver la bonne structure, les bons mots ou la bonne méthode pour obtenir exactement la réponse attendue. À ce sujet, l’article « Les prompts magiques n’existent pas » de Valeria Landivar propose une réflexion intéressante sur les limites de cette approche.
Cela ne signifie pas que la manière de formuler une demande soit sans importance. Une demande plus précise fournit davantage d’éléments au modèle et peut naturellement conduire à une réponse plus adaptée. Mais cela ne transforme pas pour autant le prompt en formule universelle.
Prenons un exemple volontairement simple dans le domaine du développement web :
Crée une page HTML pour présenter une entreprise.La demande est suffisamment claire pour qu’une IA puisse produire quelque chose. Elle générera probablement une structure HTML, un titre, quelques textes de présentation et plusieurs sections classiques. Nous pouvons observer un exemple de résultat avec « Nova Conseil | Accompagnement des entreprises ».
Nous pouvons ensuite enrichir la demande :
Crée une page HTML moderne pour présenter une entreprise de services numériques. Utilise une structure responsive, un en-tête, une section de présentation, une liste de services et un formulaire de contact.Le résultat sera généralement plus proche de ce que nous recherchons, comme le montre cette seconde proposition : « Numera | Services numériques ».
Pourquoi cette seconde demande fonctionne-t-elle mieux ? Non parce qu’elle utiliserait une combinaison particulière de mots, mais simplement parce qu’elle fournit davantage d’informations : nature de l’entreprise, type de page souhaité, comportement responsive et principales sections attendues.
De nombreuses ressources proposent justement des méthodes, des structures ou des exemples destinés à enrichir ce type de demande. Dans le domaine du développement web, nous pouvons notamment consulter Yes We Prompt, IA-Labo, le Journal du Net ou encore HubSpot. Ces ressources peuvent fournir des exemples, des méthodes ou simplement des points de comparaison utiles.
Pour autant, notre seconde demande reste loin d’être complète. Quelle entreprise devons-nous réellement présenter ? À quel public s’adresse-t-elle ? Possède-t-elle déjà une identité graphique ? Attendons-nous uniquement du HTML et du CSS ou également du JavaScript ? Les contenus doivent-ils être rédigés ou simplement matérialisés par des textes provisoires ? Quel niveau de finition recherchons-nous ?
Toutes ces informations peuvent modifier profondément le résultat.
C’est l’une des premières idées importantes à retenir : un prompt n’existe jamais réellement de manière isolée. Il s’inscrit dans un contexte, répond à un objectif et comporte des contraintes qui ne sont pas toujours visibles dans sa première formulation. Une demande efficace dans une situation donnée peut donc se révéler beaucoup moins pertinente dans une autre. C’était déjà l’un des constats centraux de la version initiale de ce chapitre.
Cela ne signifie pas qu’il faille transformer chaque question en cahier des charges. Une demande simple peut parfaitement se satisfaire de quelques mots. En revanche, plus le sujet devient précis ou complexe, plus les informations fournies prennent de l’importance.
Des ressources plus générales, comme le « Guide complet pour créer et améliorer ses prompts », peuvent aider à découvrir différentes manières d’organiser ces informations. Elles constituent des outils intéressants pour apprendre à mieux formuler une demande, mais elles ne remplacent ni la connaissance du contexte ni la compréhension du besoin.
Le prompt constitue ainsi moins une formule à perfectionner qu’un point de départ pour construire l’échange. Lorsque certaines informations manquent, elles pourront être précisées, discutées ou corrigées au fil de la conversation.
Donner suffisamment de contexte sans alourdir l’échange
Après avoir écarté l’idée d’un prompt parfait, une autre question apparaît rapidement : faut-il structurer systématiquement ses demandes ou simplement écrire comme nous le ferions dans une conversation ordinaire ?
De nombreux guides proposent des modèles destinés à organiser les informations transmises à l’IA. L’un des plus simples consiste par exemple à distinguer :
[CONTEXTE]
...
[OBJECTIF]
...
[CONTRAINTE]
...
[ATTENDU]
...Cette organisation peut être utile, mais elle ne constitue pas une syntaxe particulière que l’IA aurait besoin de recevoir pour comprendre notre demande. Elle sert surtout à nous aider à distinguer les informations importantes et à vérifier que nous n’en avons pas oublié.
Prenons un exemple relativement simple :
[CONTEXTE]
API PHP recevant des fichiers envoyés par des utilisateurs.
[OBJECTIF]
Nettoyer les caractères présents dans le nom des fichiers afin de produire un nom compatible avec le système de stockage.
[CONTRAINTE]
PHP 8.3.
[ATTENDU]
Proposer une fonction réutilisable.Nous pourrions cependant transmettre exactement les mêmes informations en langage naturel :
Je développe une API PHP 8.3 qui reçoit des fichiers envoyés par des utilisateurs. Je souhaite nettoyer les caractères présents dans les noms de fichiers afin d'obtenir des noms compatibles avec mon système de stockage. Peux-tu me proposer une fonction réutilisable ?Dans les deux cas, les informations essentielles sont présentes. La différence ne réside donc pas dans une efficacité particulière de la première formulation, mais dans la manière dont nous organisons notre propre demande.
Quand le langage naturel suffit
Pour une demande simple ou modérément complexe, une structure formelle est souvent inutile.
Explique-moi simplement le principe de l’injection de dépendances en PHP avec un exemple concret.
ou :
Peux-tu résumer cet article en cinq points clés ?Dans ces situations, ajouter artificiellement un contexte, un objectif, des contraintes et un attendu ne ferait souvent qu’alourdir l’échange. Le langage naturel reste plus direct et contient déjà suffisamment d’informations pour que la demande puisse être traitée.
La structuration ne devrait donc pas devenir un automatisme. Elle commence surtout à présenter un intérêt lorsque plusieurs informations doivent rester visibles simultanément.
Quand structurer devient utile
À mesure que la demande gagne en complexité, la structuration peut devenir intéressante. La situation change lorsque la demande rassemble un contexte métier ou technique important, plusieurs contraintes, des données, du code, des choix à comparer ou plusieurs résultats attendus.
Il ne s’agit alors plus simplement de poser une question, mais de transmettre un petit ensemble d’informations cohérent. La structure peut aider à distinguer, par exemple :
- ce qui décrit la situation ;
- ce que nous cherchons à obtenir ;
- les limites techniques ou fonctionnelles à respecter ;
- la forme sous laquelle nous souhaitons recevoir le résultat.
C’est particulièrement utile dans les projets informatiques, où une demande peut rapidement intégrer une version de langage, une architecture existante, un schéma de données, des contraintes de sécurité ou des règles métier.
[CONTEXTE]
Je développe une API REST en PHP 8.3 destinée à être utilisée par plusieurs applications internes ainsi que par une future application mobile.
La base de données MySQL contient notamment la table suivante :
CREATE TABLE tab_clients (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
numero_adherent VARCHAR(20) NOT NULL UNIQUE,
nom VARCHAR(100) NOT NULL,
prenom VARCHAR(100) NOT NULL,
email VARCHAR(255) NULL,
telephone VARCHAR(30) NULL,
date_creation DATETIME NOT NULL,
actif TINYINT(1) NOT NULL DEFAULT 1
);
L'application gère plusieurs milliers d'adhérents et certaines requêtes pourront retourner des volumes importants de données.
[OBJECTIF]
Produire un endpoint REST accessible via :
GET https://domain.com/users/adherents
permettant de retourner la liste paginée des adhérents actifs.
[CONTRAINTES TECHNIQUES]
• PHP 8.3 uniquement.
• Architecture modulaire.
• Utilisation de PDO.
• Respect des principes REST.
• Séparation des responsabilités (Controller, Service, Repository).
• Réponse JSON UTF-8.
• Pagination obligatoire.
• Gestion centralisée des erreurs.
• Préparation à une authentification future par jeton.
• Compatible avec une montée en charge progressive.
[CONTRAINTES FONCTIONNELLES]
• Les adhérents inactifs ne doivent jamais être retournés.
• Les résultats doivent être triés par nom puis prénom.
• Les paramètres page et limit doivent être disponibles.
• La valeur maximale de limit doit être plafonnée à 100.
• Les champs sensibles ne doivent pas être exposés si la structure évolue dans le futur.
[ATTENDU]
Proposer :
1. L'architecture générale du projet.
2. Les classes principales à créer.
3. Le rôle de chaque couche.
4. Le format JSON retourné.
5. Les codes HTTP utilisés.
6. Une implémentation du endpoint.
7. La gestion des erreurs.
8. Les points de vigilance concernant la sécurité.
9. Les points de vigilance concernant les performances.
10. Les évolutions possibles pour une authentification future.Ici, la structure devient réellement utile. Non parce que le modèle serait incapable de comprendre ces informations sous forme de prose, mais parce que leur nombre rend la demande plus difficile à relire et à contrôler.
Structurer ne signifie pas tout prévoir
Une demande très détaillée ne devient pas pour autant complète.
Dans l’exemple précédent, plusieurs décisions pourraient encore rester ouvertes : quel mécanisme de pagination choisir ? Quels champs doivent réellement être exposés ? Quand introduire l’authentification ? Comment anticiper une augmentation importante du volume de données ?
Ces questions ne révèlent pas un défaut du prompt. Elles montrent simplement qu’un besoin réel contient souvent des choix qui n’ont pas encore été établis, des informations implicites ou des contraintes qui n’apparaîtront que plus tard.
C’est précisément pour cette raison qu’il serait contre-productif de chercher à tout anticiper dans une demande initiale. À vouloir produire un prompt exhaustif, nous risquerions de transformer la préparation de la conversation en rédaction d’un cahier des charges alors que certaines décisions ne peuvent émerger qu’en travaillant sur le problème.
Une structure doit donc rester un outil, pas devenir une obligation.
Pour une question simple, quelques phrases suffisent. Pour un besoin plus complexe, séparer contexte, objectif, contraintes et résultat attendu peut faciliter la lecture et limiter certains malentendus. Dans les deux cas, l’essentiel reste de transmettre les informations utiles avec un niveau de précision adapté au problème posé.
Et lorsqu’une partie du besoin reste encore incertaine, il n’est pas nécessaire de la deviner ou de la figer dès le départ : elle pourra être précisée au fil de l’échange.
Orienter la réponse : ton, rôle et forme attendue
Une fois le contexte posé, la manière dont nous formulons notre demande peut encore orienter la réponse. Nous ne choisissons pas seulement ce que nous transmettons, mais également la façon dont nous demandons à l’IA de traiter ces informations.
Une injonction directe comme « Analyse ce code. » n’appelle pas tout à fait le même type de réponse que « Peux-tu analyser ce code ? ». De même, « Choisis la meilleure solution. » et « Peux-tu choisir la meilleure solution ? » expriment pratiquement la même demande, mais n’installent pas nécessairement la même dynamique d’échange.
Dans les deux cas, le fond change très peu. C’est surtout la posture de la demande qui évolue : l’une place davantage l’échange dans une logique d’exécution, l’autre dans un registre plus conversationnel. Cette différence reste subtile, mais elle permet de mieux distinguer l’effet de la formulation de celui du contenu demandé.
Cela ne signifie pas que l’IA réagit émotionnellement à notre manière de nous adresser à elle. Elle ne se sent ni respectée, ni brusquée, ni valorisée. En revanche, certaines formulations installent davantage une logique d’exécution, tandis que d’autres donnent à l’échange une tonalité plus conversationnelle et ouverte.
Le ton agit aussi sur notre propre posture
Cette différence ne concerne pas seulement la réponse produite. Elle influence aussi notre propre manière d’aborder l’échange. Lorsque nous formulons nos demandes comme des ordres, « Produis », « Corrige », « Réécris », « Continue », nous installons une logique d’exécution ; lorsque nous les formulons comme des questions ouvertes, « Que penses-tu de cette approche ? », « Peux-tu identifier les points faibles de cette solution ? », « Quelles autres pistes pourrions-nous envisager ? », nous favorisons davantage l’exploration, la comparaison ou la remise en question.
Pour approfondir cette dimension, la Politeness Theory constitue une piste intéressante. Développée à l’origine pour analyser les interactions humaines, elle aide à éclairer certains mécanismes liés au ton, à la relation et à la posture adoptée dans l’échange. Une présentation complémentaire est également proposée par Politeness Theory – EBSCO Research Starters.
Il ne s’agit donc pas de chercher à « être poli avec la machine » pour obtenir une meilleure réponse, mais plutôt de prendre conscience de la dynamique que certaines formulations installent dans la conversation.
Tutoyer, vouvoyer ou parler comme à un interlocuteur
Le même phénomène apparaît avec le tutoiement, le vouvoiement ou, plus généralement, l’emploi des codes habituels de la conversation humaine.
Certains utilisateurs tutoient spontanément une IA. D’autres préfèrent la vouvoyer. Pour le modèle, cette différence reste généralement secondaire. Pour nous, elle peut en revanche modifier la perception de l’échange : proximité dans un cas, distance dans l’autre.
Cette fluidité peut aussi favoriser une forme d’anthropomorphisme. Lorsque nous demandons « Êtes-vous d’accord avec cette analyse ? » ou « Quel serait votre avis sur cette architecture ? » nous employons naturellement des formulations réservées à des interlocuteurs humains.
Ces expressions ne posent aucun problème en elles-mêmes, mais elles peuvent rendre plus facile l’oubli d’une distinction importante : l’IA ne possède ni opinion personnelle, ni conviction, ni expérience propre. Ce point a déjà été développé plus largement dans « Comprendre les IA conversationnelles : dialogue, apprentissage et illusion de compréhension ».
Pour approfondir cette dimension particulière de l’échange, plusieurs travaux peuvent être consultés :
- Anthropomorphism of AI based chatbots by users during communication ;
- The role of politeness in human–machine interactions: a systematic literature review and future perspectives ;
- Should We Respect LLMs? A Cross-Lingual Study on the Influence of Prompt Politeness on LLM Performance ;
- Mind Your Tone: Investigating How Prompt Politeness Affects LLM Accuracy.
Ces travaux ne conduisent pas nécessairement aux mêmes conclusions, mais ils montrent que le ton, la perception de la machine et la forme des réponses entretiennent des relations plus complexes qu’une simple opposition entre « prompt poli » et « prompt autoritaire ».
Demander un rôle ou une posture
Nous pouvons également orienter explicitement l’angle sous lequel l’IA doit examiner un problème « Agis comme un relecteur technique. », « Joue le rôle d’un développeur senior chargé d’auditer ce code. », « Comporte-toi comme un contradicteur et cherche les faiblesses de mon raisonnement. ». Dans ce cas, nous ne transformons évidemment pas l’IA en relecteur, en développeur senior ou en consultant. Nous lui indiquons plutôt le type de regard que nous attendons sur le problème.
Une même situation pourra ainsi être abordée sous un angle pédagogique, critique, technique ou synthétique. Le rôle demandé sert surtout à orienter l’attention vers certains aspects de la réponse.
Cette pratique est généralement désignée sous les termes de role prompting, persona prompting ou instruction prompting. Pour une présentation de la première approche, voir Role Prompting : pourquoi attribuer un persona à l’IA. On pourra également consulter les ressources consacrées au persona prompting et à l’instruction prompting.
Ces approches sont largement étudiées dans les travaux consacrés aux grands modèles de langage. Dans la pratique quotidienne, leur intérêt dépasse cependant largement le cadre du prompt engineering : elles servent surtout à préciser l’angle, la posture ou le type d’aide que nous attendons de la conversation.
Demander à l’IA d’agir « comme un expert » ne lui apporte pas pour autant de nouvelles connaissances. L’étude Personas in System Prompts Do Not Improve Performance rappelle notamment que l’ajout d’une persona ne conduit pas automatiquement à de meilleures performances. De son côté, When Does Persona Prompting Actually Help? A Retrieval and Metric Analysis of Expert Role Injection in LLMs observe que le persona prompting modifie surtout la nature des réponses produites : elles peuvent devenir plus techniques, plus structurées ou plus professionnelles, sans être systématiquement meilleures.
Pour approfondir cette pratique sous un angle plus opérationnel, l’article On Persona Prompting. Language as LLM Control Surface constitue également une ressource utile.
Préciser le niveau de détail
Une autre source fréquente d’insatisfaction ne concerne pas nécessairement le contenu de la réponse, mais sa longueur. Nous pouvons attendre quelques lignes alors que l’IA développe plusieurs pages, ou au contraire recevoir une synthèse alors que nous cherchions une analyse détaillée.
Il peut donc être utile de préciser simplement « Réponds en quelques phrases. », « Développe chaque point avec un exemple concret. », « Commence par une synthèse, puis détaille si nécessaire. ». Cette manière d’expliciter la longueur, le niveau de précision ou la forme attendue rejoint les recommandations générales présentées dans OpenAI Academy – Prompting.
Ces indications ne changent pas le fond du problème. Elles permettent surtout d’adapter la profondeur de la réponse à l’usage que nous voulons en faire.
Préciser la forme de restitution
La même logique vaut pour le format « Présente la réponse sous forme de tableau. », « Fournis uniquement une liste d’étapes. », « Utilise le format Markdown. », « Rédige un texte prêt à être publié. »
Ici encore, nous n’améliorons pas les connaissances du modèle. Nous précisons simplement comment nous souhaitons récupérer et réutiliser le résultat. Cette indication peut être particulièrement utile lorsqu’une réponse doit être intégrée dans une documentation, un article, un programme ou un autre outil.
Ces différentes pratiques appartiennent plus largement à ce que l’on regroupe sous le terme de prompt engineering. Leur intérêt quotidien reste toutefois assez simple : il s’agit moins de découvrir une technique cachée que d’exprimer clairement quel type d’aide nous recherchons.
Orienter ne signifie pas garantir
Aucune de ces indications ne garantit une réponse juste ou pertinente. Une IA à laquelle nous demandons d’agir comme contradicteur peut manquer un problème important. Une réponse demandée sous forme de tableau peut être parfaitement structurée et contenir une information erronée. Un ton plus ouvert peut favoriser l’exploration sans pour autant produire une meilleure conclusion.
Le rôle, le ton, le niveau de détail ou le format servent principalement à rapprocher la réponse de l’usage que nous voulons en faire. Ils orientent la conversation ; ils ne remplacent ni le contexte, ni la vérification, ni notre jugement.
C’est peut-être là le point commun entre toutes ces pratiques : elles ne rendent pas nécessairement l’IA plus compétente. Elles nous permettent surtout de mieux préciser la place que nous souhaitons lui donner dans l’échange.
Construire la réponse par étapes
Lorsque nous travaillons avec une IA conversationnelle, la tentation est souvent grande de vouloir obtenir immédiatement une solution complète. Si le modèle peut analyser du code, proposer une architecture, rédiger une documentation ou produire des exemples, pourquoi ne pas tout demander en une seule fois ?
Cette approche peut fournir une première vision d’ensemble intéressante. Mais plus une demande couvre de sujets différents, plus l’IA doit combler elle-même les zones d’incertitude. Elle interprète le contexte, formule des hypothèses, choisit certaines orientations et construit progressivement une réponse qui peut sembler cohérente tout en reposant sur des décisions qui n’ont jamais été discutées.
Une réponse impressionnante n’est pas forcément une bonne réponse
Les IA conversationnelles peuvent produire très rapidement une grande quantité de contenu : plusieurs pages d’explications, des dizaines de fonctions, une architecture complète ou encore un plan détaillé de projet.
Cette abondance peut donner l’impression que le problème est déjà largement résolu. Pourtant, une réponse volumineuse n’est pas nécessairement une réponse adaptée. Plus le modèle doit prendre de décisions à notre place, plus il risque de construire sur des hypothèses implicites. Le résultat peut être convaincant à la lecture tout en s’éloignant progressivement du besoin réel.
Cette approche progressive rejoint plusieurs réflexions déjà développées dans Concevoir nos applications depuis le terrain : écouter les besoins, construire par le code et Tracer des solutions : du code à l’usage, où nous insistions déjà sur l’intérêt de faire émerger les besoins, de confronter progressivement les hypothèses à la réalité et d’affiner une solution au fil de sa construction.
Clarifier avant de produire
Dans un projet réel, le besoin est rarement parfaitement défini dès le départ. Une idée générale existe, mais certaines contraintes, certains usages ou certains objectifs apparaissent seulement lorsque nous commençons à examiner le problème.
Avant de demander immédiatement du code ou une solution complète, il peut donc être utile de revenir à quelques questions simples : « Quel problème cherchons-nous réellement à résoudre ? », « Qui utilisera la solution ? », « Quelles contraintes techniques ou organisationnelles devons-nous respecter ? », ou encore « Quelles limites pouvons-nous accepter ? ».
Cette phase de clarification paraît parfois moins spectaculaire que la génération immédiate de centaines de lignes de code. Elle permet pourtant d’éviter de construire rapidement une solution parfaitement fonctionnelle, mais qui répond mal au problème posé.
Cette manière de procéder rejoint également l’idée développée dans Apprendre à raisonner plutôt qu’apprendre des outils : la qualité d’une solution dépend souvent davantage de la compréhension du problème que de la technologie employée.
Découper la réflexion pour mieux avancer
Dans le développement web, nous travaillons rarement sur un projet entier en une seule étape. Nous distinguons naturellement plusieurs sujets : analyse du besoin, architecture, données, interfaces, sécurité, tests ou déploiement.
Le dialogue avec une IA peut suivre la même logique. Une première discussion peut servir à préciser le besoin, une seconde à identifier les fonctionnalités principales, une autre à examiner la structure des données. Les choix techniques, l’architecture ou le code peuvent intervenir ensuite, lorsque certaines orientations commencent à être stabilisées.
Cette démarche réduit le nombre d’hypothèses implicites et facilite les corrections lorsque de nouvelles informations apparaissent. Elle rejoint les principes développés dans Algorithmique : penser les traitements avant les langages : avant de choisir un langage, un framework ou une implémentation, il reste nécessaire de comprendre la logique du problème à résoudre. Les IA conversationnelles peuvent accélérer certaines étapes, mais elles ne remplacent ni l’analyse ni la conception.
Cette démarche rejoint également les réflexions développées dans Dessiner avant de coder : méthode analogique pour penser une application, où nous évoquions déjà l’intérêt de représenter un problème, de le décomposer et d’en explorer progressivement les différentes composantes avant de passer à l’implémentation.
Bien entendu, cette répartition dépendra du projet. Certaines applications nécessiteront des échanges spécifiques autour des performances, de l’accessibilité, du référencement, des API, de l’hébergement ou encore de la maintenance. L’objectif n’est pas de figer une méthode universelle, mais de montrer comment un besoin global peut progressivement être transformé en plusieurs échanges plus ciblés.
Reformuler, valider et corriger
L’un des intérêts d’une IA conversationnelle réside précisément dans le fait qu’une première réponse n’a pas besoin d’être définitive. Elle peut être reformulée, corrigée, simplifiée ou complétée.
Il devient alors possible de demander « Résume ce que tu as compris du besoin. », « Quels points te semblent encore ambigus ? », « Quels risques vois-tu dans cette approche ? », ou encore « Quelles hypothèses avons-nous faites jusqu’ici ? ».
Ces étapes intermédiaires permettent de vérifier régulièrement que la conversation reste alignée avec le problème initial. Dans bien des cas, quelques validations successives apportent davantage de valeur qu’une réponse gigantesque obtenue dès le premier message.
L’IA peut alors servir à reformuler une idée, identifier une contrainte oubliée, comparer plusieurs approches ou questionner une hypothèse avant que nous décidions de la suite. La conversation devient moins une succession de commandes qu’un espace dans lequel la réflexion peut se construire progressivement.
Une conversation peut être plus utile qu’une réponse
Cette progression change également la manière d’évaluer l’utilité de l’IA.Si nous attendons uniquement un résultat final, nous mesurerons facilement la qualité de l’échange à la quantité ou à la finition de ce qui est produit. Mais lorsqu’un problème est complexe, une conversation peut apporter autre chose : faire apparaître une hypothèse fragile, révéler une contrainte oubliée, comparer plusieurs pistes ou nous obliger à préciser ce que nous cherchons réellement.
Dans cette perspective, une conversation peut être plus utile qu’une réponse.
L’objectif n’est donc pas nécessairement d’obtenir immédiatement la solution la plus complète possible, mais d’utiliser le dialogue pour réduire progressivement les incertitudes avant de décider et de produire.
Garder la maîtrise de la conversation
Construire une réponse par étapes permet de réduire les hypothèses et de mieux contrôler les choix effectués au fil de l’échange. Mais cette progression comporte aussi un risque : la conversation peut progressivement devenir plus complexe que le problème qu’elle devait résoudre.
Une amélioration en appelle une autre, puis une optimisation, une nouvelle fonctionnalité, une abstraction supplémentaire ou une dépendance qui semblait jusque-là inutile. La solution gagne alors en sophistication sans nécessairement gagner en pertinence. Ce phénomène n’est pas propre aux IA ; il existe également dans les projets conçus uniquement par des humains. Les IA conversationnelles peuvent cependant l’accélérer, simplement parce qu’elles sont capables de proposer rapidement de nombreuses pistes et variantes.
Quand la solution dépasse le besoin
Dans une longue conversation technique, une proposition peut sembler intéressante en elle-même sans être réellement nécessaire au projet.
Une architecture plus élaborée, une fonctionnalité supplémentaire ou une optimisation peuvent toutes être défendables d’un point de vue technique. Cela ne signifie pas pour autant qu’elles répondent au besoin initial.
Il devient alors utile de revenir régulièrement à quelques questions simples : « Quel problème cherchons-nous à résoudre ? », « Cette fonctionnalité apporte-t-elle réellement quelque chose ? », « Cette complexité supplémentaire est-elle justifiée ? », ou encore « Sommes-nous toujours en train de répondre à la question initiale ? ».
Ces questions permettent de conserver une vision d’ensemble et d’éviter que la conversation ne transforme progressivement le projet en autre chose que ce que nous cherchions à construire.
Dans bien des situations, la meilleure décision consiste d’ailleurs à ne pas suivre une suggestion, même lorsqu’elle semble techniquement pertinente.
Une proposition plus sophistiquée n’est pas nécessairement une meilleure proposition. Une solution plus simple peut être plus lisible, plus facile à maintenir et surtout mieux adaptée au besoin réel.
Accepter de ne pas tout retenir
L’intérêt d’une IA conversationnelle ne réside donc pas seulement dans sa capacité à produire des idées, du texte ou du code. Il réside aussi dans la possibilité de les examiner, de les discuter et, lorsque cela paraît nécessaire, de les écarter.
Cette distinction est importante. Une suggestion n’est pas une décision. L’IA peut proposer plusieurs solutions, attirer notre attention sur un risque ou nous présenter une alternative que nous n’avions pas envisagée. Il nous appartient ensuite de déterminer si cette proposition correspond réellement aux objectifs du projet.
Le dialogue reste alors un outil d’exploration : il enrichit les possibilités sans nous obliger à les adopter.
Savoir interrompre la conversation
Une autre forme de dérive consiste à poursuivre indéfiniment l’échange dans l’espoir d’obtenir une réponse toujours meilleure.
Chaque nouvelle question peut faire apparaître une autre possibilité, une variante supplémentaire ou une amélioration potentielle. Il devient alors facile de prolonger la réflexion sans jamais passer réellement à l’action. Cette situation rappelle un problème bien connu dans de nombreux projets : la recherche de la solution idéale peut retarder la réalisation d’une solution simplement suffisante.
À partir d’un certain point, les nouveaux échanges apportent de moins en moins d’informations réellement utiles. Continuer à analyser ne garantit plus une meilleure décision ; cela peut simplement reporter le moment où cette décision doit être prise.
Savoir dialoguer avec une IA consiste donc aussi à reconnaître ce moment. Nous pouvons alors nous demander « Avons-nous suffisamment d’éléments pour décider ? », « Les principales zones d’incertitude ont-elles été levées ? », ou encore « Une nouvelle discussion modifierait-elle réellement notre choix ? ». Lorsque la réponse devient négative, poursuivre la conversation apporte peu de valeur supplémentaire.
Revenir au terrain
L’IA peut aider à explorer, comparer, reformuler ou préparer une décision. Elle ne remplace cependant pas le moment où il faut agir.
À un moment donné, il faut écrire le code, effectuer les tests, produire le document, confronter la solution aux utilisateurs ou simplement vérifier sur le terrain si ce que nous avons imaginé fonctionne réellement.
Les arbitrages et les priorités restent donc de notre responsabilité. Le rôle du dialogue n’est pas de retarder indéfiniment cette décision, mais de nous fournir les éléments nécessaires pour la prendre.
Savoir interrompre une conversation avec une IA fait ainsi pleinement partie de la manière de bien l’utiliser. Le but n’est pas de poursuivre l’échange jusqu’à obtenir une réponse supposée parfaite, mais de savoir quand nous disposons de suffisamment d’éléments pour avancer.
À ce moment-là, il faut quitter la conversation et revenir au code, aux tests, à la rédaction, aux utilisateurs ou au terrain.
Le contexte de la conversation compte aussi
Depuis le début de cet article, nous nous sommes surtout intéressés à la manière de formuler une demande, de préciser le résultat attendu ou de faire évoluer progressivement un échange. Mais la qualité d’une conversation ne dépend pas uniquement de ce que nous écrivons dans un message. L’environnement dans lequel le dialogue se déroule influence également ce que l’IA reçoit, conserve ou réutilise au fil du temps.
Deux personnes utilisant un même modèle peuvent ainsi obtenir des expériences différentes sans pour autant employer des prompts radicalement différents. L’historique disponible, les directives permanentes, l’organisation des conversations ou encore l’interface utilisée peuvent modifier le contexte dans lequel une nouvelle demande sera interprétée.
Les directives permanentes ne sont pas neutres
De nombreuses interfaces permettent aujourd’hui de définir des préférences ou des instructions destinées à être appliquées à plusieurs conversations. Nous pouvons par exemple demander à l’IA de privilégier les réponses courtes, de signaler les incertitudes, d’adopter une approche critique ou encore de respecter certaines conventions de rédaction.
Ces directives peuvent être utiles lorsqu’elles correspondent à un usage récurrent. Elles évitent de répéter certaines attentes et permettent de maintenir une forme de cohérence dans les échanges.
Elles ne doivent pourtant pas être considérées comme universellement bénéfiques. Une règle pertinente dans un contexte peut devenir gênante dans un autre. Exiger systématiquement des sources, interdire toute hypothèse ou imposer une méthode particulière peut renforcer le contrôle dans certaines situations, mais aussi réduire la souplesse de l’exploration lorsque nous cherchons simplement à faire émerger des pistes.
L’intérêt d’une directive permanente dépend donc moins de sa sophistication que de son adéquation avec l’usage auquel elle est destinée.
Organiser les conversations pour retrouver le contexte utile
Une autre question apparaît lorsque les échanges se multiplient : faut-il ouvrir une nouvelle conversation pour chaque sujet ou conserver un même fil afin de bénéficier du contexte déjà accumulé ?
Il n’existe pas ici non plus de méthode universelle. Certains utilisateurs préfèrent séparer strictement les projets ou les thèmes. D’autres conservent de longues conversations dans lesquelles décisions, hypothèses, corrections et ressources s’accumulent progressivement.
Cette question rejoint plus largement les pratiques de gestion personnelle des connaissances. Le guide Gestion des connaissances personnelles (PKM) : le guide complet propose une introduction à ces démarches d’organisation de l’information. Dans un autre registre, Le réseau personnel de gestion des connaissances et la redéfinition du travail montre comment les outils numériques participent à la constitution d’environnements personnels dans lesquels nous organisons et mobilisons progressivement nos connaissances.
Avec une IA conversationnelle, la conversation devient elle-même l’un de ces espaces : elle contient des informations, des hypothèses, des décisions et parfois des éléments produits plusieurs jours auparavant.
L’essentiel reste donc de pouvoir retrouver ce qui est utile au moment où nous en avons besoin, sans transformer l’organisation des conversations en système plus complexe que le travail qu’elle doit faciliter.
Le contexte implicite s’accumule
Lorsqu’une conversation se poursuit pendant plusieurs jours ou plusieurs semaines, toutes les informations utiles ne sont plus nécessairement répétées à chaque message.
Des choix effectués précédemment, des préférences exprimées, des hypothèses de travail ou des décisions déjà prises peuvent continuer à influencer l’échange. Une partie du contexte devient alors implicite.
Pour approfondir cette distinction entre ce qui est formulé directement et ce qui est déduit des échanges précédents, le dossier Le contexte : implicite/explicite fournit une présentation générale de cette notion.
Cette continuité présente un avantage évident : nous pouvons reprendre un sujet sans reconstruire entièrement son historique. La conversation constitue alors une forme de contexte de travail partagé dans lequel certaines décisions restent disponibles pour la suite. Sans être directement transposable au fonctionnement d’une IA conversationnelle, la notion de Working Memory Model, issue de la psychologie cognitive, aide à éclairer cette idée : certaines informations sont temporairement maintenues afin de pouvoir raisonner, résoudre un problème ou prendre une décision.
Mais cet avantage possède son revers. Une hypothèse abandonnée peut continuer à influencer une réponse. Une orientation devenue obsolète peut réapparaître plusieurs échanges plus tard. Plus la conversation s’allonge, plus il devient donc utile de vérifier que les informations héritées du passé correspondent encore à la direction actuelle du projet.
Il peut parfois être préférable de poursuivre le même échange afin de profiter de cette continuité. Dans d’autres situations, repartir dans une nouvelle conversation en reformulant explicitement le contexte pertinent permet d’écarter des éléments devenus inutiles.
Une même IA ne signifie pas nécessairement une même expérience
Le contexte dépend également de l’environnement utilisé. Une même question posée depuis une interface web, une application mobile, une API ou un outil intégré à un environnement de développement peut être traitée dans des conditions légèrement différentes. L’historique transmis, les instructions appliquées ou les outils accessibles ne sont pas nécessairement identiques.
Ces différences expliquent en partie pourquoi il est parfois difficile de comparer deux réponses en se fondant uniquement sur le nom du modèle utilisé.
L’une des personnes dispose peut-être d’un historique construit depuis plusieurs semaines, tandis que l’autre commence une conversation vierge. L’une travaille avec des directives permanentes précises, l’autre sans instruction particulière. L’une utilise simplement une interface conversationnelle, tandis que l’autre s’appuie sur une API, un IDE ou un workflow intégrant d’autres outils.
Comparer uniquement les modèles revient alors à ignorer une partie importante de l’équation. Comme nous l’avons déjà évoqué dans IA conversationnelles et développement web : dépasser les effets de mode, la qualité d’un échange résulte généralement de l’interaction entre un utilisateur, un contexte, une méthode de travail et l’outil employé.
Nous reviendrons plus précisément sur ces environnements et leurs différences dans la suite de cette série, notamment dans « IA conversationnelle, assistants, agents, workflows : comprendre les briques derrière les outils ». Retenons ici qu’une conversation ne se résume pas à l’enchaînement visible de nos questions et des réponses produites : elle s’inscrit dans un environnement qui participe lui aussi à la construction du contexte.
Conclusion : Dialoguer, mais rester aux commandes
Avec le temps, chacun développe progressivement sa propre manière de dialoguer avec une IA conversationnelle. Certains privilégient les demandes courtes et directes, d’autres fournissent un contexte plus élaboré dès le départ. Certains avancent par échanges successifs, tandis que d’autres utilisent davantage les reformulations, les comparaisons ou les validations intermédiaires.
Il n’existe pas de méthode unique qui conviendrait à tous ces usages. Un développeur, un rédacteur, un enseignant ou un responsable associatif ne rechercheront pas nécessairement les mêmes types de réponses ni les mêmes formes d’échange. L’expérience consiste donc moins à adopter une méthode présentée comme idéale qu’à identifier progressivement celle qui correspond à notre manière de travailler et aux problèmes que nous rencontrons.
Les techniques évoquées au fil de cet article peuvent aider : préciser le contexte, structurer une demande lorsque cela devient utile, indiquer un rôle ou un format, travailler par étapes, reformuler ou recentrer régulièrement la conversation. Mais aucune d’elles ne transforme une réponse en vérité simplement parce qu’elle a été correctement demandée.
Une formulation convaincante, un raisonnement apparemment cohérent ou une réponse particulièrement bien structurée peuvent donner une impression de solidité. Pourtant, une IA peut toujours interpréter incorrectement un contexte, oublier une contrainte, proposer une information discutable ou développer avec assurance une hypothèse fragile.
Apprendre à dialoguer avec ces outils implique donc aussi d’apprendre à conserver une certaine distance face à ce qu’ils produisent.
Cette vigilance devient particulièrement importante dans les conversations longues. De nouvelles idées apparaissent, certaines pistes se révèlent utiles, d’autres nous éloignent progressivement du besoin initial. Il faut alors savoir revenir aux objectifs de départ, remettre en question une proposition, vérifier une information ou simplement décider qu’une piste ne mérite pas d’être poursuivie.
La qualité d’un échange avec une IA ne dépend ainsi pas uniquement de la pertinence de ses réponses. Elle dépend également de notre capacité à exercer notre jugement, à vérifier ce qui doit l’être, à conserver une vision d’ensemble et à décider quelles propositions méritent réellement d’être retenues.
L’IA peut participer à une réflexion, nous aider à explorer un problème, faire apparaître des alternatives ou nous conduire à reformuler ce que nous cherchons. Mais les arbitrages restent humains.
L’objectif n’est donc pas de déléguer notre réflexion à l’IA, mais de l’enrichir grâce au dialogue.
