Module 06 — Cas pratiques par domaine professionnel

---

Ce que vous allez apprendre

Vous voici au dernier module. Tout ce que vous avez appris jusqu’ici — les quatre piliers, le Chain-of-Thought, le Role Prompting, le Tree-of-Thought, le Prompt Chaining, la gestion des erreurs — va maintenant prendre corps dans des situations réelles, avec des prompts complets, commentés, et directement adaptables à votre propre contexte.

Ce module est organisé autour de quatre domaines professionnels : le marketing et le copywriting, l’analyse de données et la business intelligence, l’éducation et la pédagogie, et le développement logiciel. Pour chaque domaine, vous allez voir plusieurs cas d’usage traités de bout en bout — du diagnostic du besoin à la construction du prompt, jusqu’à la lecture critique du résultat. Vous allez comprendre non seulement ce que le prompt fait, mais pourquoi chaque choix a été fait.

À la fin de ce module, vous ne repartez pas avec des exemples à copier-coller. Vous repartez avec une façon de penser qui vous permet de construire le bon prompt pour n’importe quelle situation que vous n’avez pas encore rencontrée.

---

Domaine 1 — Marketing et Copywriting

Pourquoi le marketing est un terrain idéal

Le marketing est l’un des domaines où le prompt engineering apporte les bénéfices les plus immédiats. La raison est structurelle : le marketing produit d’énormes volumes de contenu répétitif — accroches, slogans, emails, fiches produits, posts réseaux sociaux, scripts vidéo — dont chaque pièce doit être à la fois cohérente avec une identité de marque et adaptée à un contexte précis. C’est exactement la combinaison de contraintes que les LLM gèrent le mieux, à condition d’être correctement guidés.

Il y a aussi une dimension de test et d’itération qui rend les LLM particulièrement précieux en marketing. Générer dix variantes d’une accroche pour tester laquelle performe le mieux en A/B test était autrefois une tâche qui mobilisait une demi-journée d’un copywriter senior. Avec un prompt bien construit, c’est une question de minutes.

Cas 1 — Générer des variantes de slogan avec ciblage par persona

Le besoin. Vous lancez une application mobile de méditation pour les professionnels. Vous avez identifié trois personas distincts — le cadre stressé qui manque de temps, le manager en quête de performance cognitive, et le jeune professionnel qui cherche un équilibre vie pro/vie perso. Vous avez besoin de slogans différents pour chaque persona, à tester dans des campagnes séparées.

Ce que ferait un utilisateur non formé. Il taperait quelque chose comme “génère des slogans pour une application de méditation”. Il obtiendrait cinq slogans génériques et interchangeables, applicables à n’importe quelle app de bien-être sur le marché, et qui ne parlent à aucun persona en particulier.

Le raisonnement derrière le prompt. Vous avez besoin d’un rôle précis — un copywriter senior qui comprend à la fois la psychologie des personas et les contraintes d’un slogan efficace. Vous devez fournir suffisamment de contexte sur le produit pour que les slogans soient différenciants. Vous devez décrire chaque persona avec les mots qui activent les bons ressorts émotionnels. Et vous devez spécifier un format de sortie qui vous permet de comparer facilement les variantes.

Le prompt.

Tu es un directeur artistique et copywriter senior avec quinze ans d’expérience en marketing digital pour des produits de bien-être et de productivité. Tu as travaillé pour des marques comme Headspace et Calm et tu connais parfaitement les codes de communication qui résonnent avec les professionnels actifs.

Le produit : une application mobile de méditation guidée appelée “Ancre”. Elle propose des sessions de trois à douze minutes, conçues pour être pratiquées au bureau ou dans les transports. Son positionnement : la méditation sans l’ésotérisme — concrète, efficace, mesurable. L’application affiche des données sur l’évolution du niveau de stress et de concentration de l’utilisateur.

Tu dois générer des slogans pour trois personas distincts. Pour chaque persona, génère trois variantes de slogan de huit mots maximum. Les slogans doivent être différenciants, mémorables, et refléter précisément le bénéfice central pour ce persona.

Persona A — Le cadre stressé : 42 ans, directeur commercial, agenda surchargé, sentiment permanent de manquer de temps. Il ne croit pas vraiment à la méditation mais est prêt à essayer n’importe quoi pour tenir le rythme. Son bénéfice clé : récupérer vite, pas se ressourcer lentement.

Persona B — Le manager performant : 38 ans, directeur de projet, convaincu que les meilleurs leaders gèrent leur état mental comme un actif. Il s’intéresse à la neuroscience et au biohacking. Son bénéfice clé : optimiser ses capacités cognitives, pas se détendre.

Persona C — Le jeune professionnel en quête d’équilibre : 28 ans, consultant junior, début de carrière intense, premières tensions entre ambition professionnelle et vie personnelle. Son bénéfice clé : tenir sur la durée sans sacrifier ce qui compte.

Format de sortie : un tableau avec quatre colonnes — Persona, Variante, Slogan, Bénéfice activé. Neuf lignes au total, trois par persona.

Pourquoi ce prompt fonctionne. Le rôle active le bon registre professionnel et fournit des références crédibles. Le contexte produit — nom, positionnement, différenciateur — donne aux slogans une matière concrète à exploiter. Chaque persona est décrit avec suffisamment de précision pour que ses ressorts émotionnels soient clairs. La contrainte des huit mots force la concision. Le format tableau facilite la comparaison et le partage avec une équipe.

---

Cas 2 — Rédiger une séquence d’emails de nurturing

Le besoin. Vous avez une liste de prospects qui ont téléchargé un livre blanc sur la gestion de la relation client. Ils connaissent votre marque mais n’ont pas encore pris contact. Vous voulez une séquence de trois emails espacés sur deux semaines pour les amener progressivement vers une demande de démonstration.

Le raisonnement. Une séquence d’emails a une logique narrative — chaque email s’appuie sur le précédent et prépare le suivant. C’est un cas typique où le Prompt Chaining est plus efficace qu’un prompt unique. Vous allez d’abord définir la stratégie narrative de la séquence, puis rédiger chaque email séparément en lui passant cette stratégie comme contexte.

Prompt 1 — La stratégie narrative.

Tu es un expert en email marketing B2B spécialisé dans les séquences de nurturing pour des logiciels SaaS. Tu maîtrises les principes de la persuasion progressive et du storytelling d’entreprise.

Contexte : notre prospect a téléchargé un livre blanc sur la gestion de la relation client. Il sait que nous existons mais n’a jamais interagi avec nous au-delà de ce téléchargement. Notre produit est une plateforme CRM pour PME de vingt à deux cents salariés. Notre positionnement : le seul CRM pensé pour les équipes commerciales qui détestent les CRM — simple à adopter, rapide à configurer, résultats visibles en trente jours.

Définis la stratégie narrative pour une séquence de trois emails sur deux semaines. Pour chaque email, précise : l’objectif psychologique de cet email dans la progression, l’angle principal, le type de preuve ou d’illustration à mobiliser, et l’appel à l’action adapté à ce stade de la relation. Ne rédige pas les emails — définis seulement la stratégie.

Une fois cette stratégie produite et validée par vous, vous rédigez chaque email avec un prompt dédié qui prend la stratégie comme contexte d’entrée. Chaque email bénéficie d’une attention complète, et vous pouvez ajuster la stratégie à mi-parcours si le premier email ne performe pas comme attendu.

---

Cas 3 — Analyser et améliorer un texte existant

Le besoin. Vous avez une page de vente qui ne convertit pas. Vous sentez qu’il y a des problèmes mais vous ne les identifiez pas clairement.

Le prompt — audit en deux temps.

Prompt d’audit :

Tu es un expert en conversion copywriting avec une spécialisation en psychologie de la persuasion. Tu as audité des centaines de pages de vente et tu sais identifier précisément ce qui freine la conversion.

Voici la page de vente à auditer : [texte de la page]

Réalise un audit structuré en trois parties. Première partie : identifie les trois problèmes les plus critiques pour la conversion, en expliquant pour chacun le mécanisme psychologique qu’il active négativement chez le lecteur. Deuxième partie : identifie les deux éléments qui fonctionnent bien et qu’il ne faut surtout pas modifier. Troisième partie : propose un ordre de priorité pour les corrections, avec une justification.

Ne réécris rien à ce stade — analyse uniquement.

Après avoir pris connaissance de l’audit et décidé des priorités, vous lancez un second prompt de réécriture ciblée, armé d’une compréhension précise de ce qui doit changer et pourquoi. Cette séparation entre l’analyse et la réécriture est ce qui garantit que les modifications apportées sont fondées sur une logique claire, pas sur l’intuition du modèle.

---

Domaine 2 — Analyse de données et Business Intelligence

Pourquoi les LLM sont précieux pour l’analyse

Une idée reçue veut que les LLM soient utiles pour produire du texte mais limités pour traiter des données. C’est partiellement vrai — ils ne remplacent pas des outils comme Python ou SQL pour manipuler de grandes masses de données brutes. Mais ils sont exceptionnellement bons pour quelque chose que ces outils font mal : interpréter des données, contextualiser des chiffres, identifier les implications stratégiques d’une évolution, et formuler des conclusions intelligibles pour des décideurs non-spécialistes.

La combinaison la plus puissante est souvent celle-ci : les outils techniques traitent les données et produisent des chiffres, les LLM transforment ces chiffres en narratif stratégique exploitable.

Cas 1 — Transformer des chiffres en diagnostic actionnable

Le besoin. Vous êtes responsable commercial dans une entreprise de logiciels. Vous avez les chiffres de votre dernier trimestre et vous devez préparer une présentation pour le comité de direction qui attend non seulement des faits mais des explications et des recommandations.

Le prompt.

Tu es un analyste business senior avec une spécialisation en SaaS et une forte expérience en présentation à des comités de direction. Tu sais transformer des données brutes en narratif stratégique clair et actionnable.

Voici les données du trimestre écoulé : — Chiffre d’affaires : 1,4 million d’euros, en hausse de 8 % par rapport au même trimestre l’année précédente. — Nombre de nouveaux clients : 23, en baisse de 15 % par rapport au trimestre précédent. — Taux de churn : 4,2 %, en hausse de 1,1 point par rapport au trimestre précédent. — Panier moyen des nouveaux clients : 18 500 euros, en hausse de 28 %. — Délai moyen de closing : 67 jours, en hausse de 12 jours. — Taux de conversion des leads qualifiés : 22 %, stable.

Raisonne étape par étape. D’abord, identifie les trois signaux les plus importants dans ces données — qu’ils soient positifs ou négatifs. Ensuite, pour chaque signal, formule une hypothèse explicative en t’appuyant sur les corrélations visibles dans les données. Enfin, pour chaque hypothèse, propose une action de vérification concrète et, si l’hypothèse se confirme, une mesure corrective ou amplificatrice selon le cas.

Format de sortie : pour chaque signal, une section structurée avec les sous-titres Signal, Hypothèse, Vérification, et Action. Termine par un paragraphe de synthèse de cinq phrases maximum pour le comité de direction, rédigé dans un style décisionnel direct.

Ce que ce prompt fait bien. Le Chain-of-Thought — “raisonne étape par étape” — force une progression logique qui évite les conclusions hâtives. La structure signal/hypothèse/vérification/action est une boucle épistémique rigoureuse qui distingue ce qu’on sait, ce qu’on suppose, et ce qu’on doit faire pour savoir. Le format dual — section détaillée pour l’analyste, synthèse pour le comité — produit un document qui sert deux audiences différentes sans les confondre.

---

Cas 2 — Construire une grille d’analyse comparative

Le besoin. Vous évaluez trois solutions logicielles pour équiper votre équipe. Vous avez collecté des informations hétérogènes sur chacune — des fiches commerciales, des avis utilisateurs, des informations de pricing, des retours de démonstrations. Vous devez produire une analyse comparative structurée pour aider à la décision.

Le prompt.

Tu es un consultant en transformation digitale spécialisé dans la sélection et l’implémentation de solutions logicielles pour des PME. Tu as mené des dizaines de projets de sélection et tu sais ce qui compte vraiment au-delà des argumentaires commerciaux.

Voici les informations collectées sur les trois solutions :

Solution A : [informations] Solution B : [informations] Solution C : [informations]

Réalise une analyse comparative structurée selon les six critères suivants, dans cet ordre de priorité : facilité d’adoption par des équipes non-techniques, richesse fonctionnelle pour nos besoins spécifiques, qualité du support et de l’accompagnement, coût total de possession sur trois ans, capacité d’intégration avec nos outils existants, et solidité et pérennité de l’éditeur.

Pour chaque critère, attribue une note de 1 à 5 à chaque solution et justifie ta note en deux ou trois phrases. Signale explicitement les informations que tu ne peux pas évaluer faute de données suffisantes.

Termine par une recommandation argumentée qui prend en compte non seulement les notes individuelles mais aussi les interactions entre critères — une faiblesse sur un critère peut être rédhibitoire même avec de bons scores sur les autres.

L’instruction finale — “prend en compte les interactions entre critères” — est particulièrement importante. Elle pousse le modèle au-delà d’une simple moyenne arithmétique vers un raisonnement décisionnel plus sophistiqué, qui reconnaît qu’une faiblesse critique peut invalider une solution malgré de bons scores globaux.

---

Cas 3 — Produire un rapport exécutif à partir d’une analyse technique

Le besoin. Votre équipe data a produit une analyse technique détaillée de l’évolution des comportements d’achat de vos clients. Le document fait trente pages et est rempli de graphiques, de corrélations et de régressions. Votre directeur général a besoin d’une synthèse d’une page pour sa réunion du lendemain.

Le prompt.

Tu es un expert en communication executive, spécialisé dans la traduction d’analyses techniques complexes en narratifs stratégiques accessibles à des dirigeants.

Voici le rapport technique à synthétiser : [contenu du rapport]

Produis une synthèse exécutive d’une page — environ quatre cents mots — structurée en trois parties. La première partie, intitulée Ce que les données révèlent, expose les deux ou trois insights les plus significatifs en langage non-technique, sans chiffres superflus — seulement ceux qui sont indispensables pour comprendre l’ampleur du phénomène. La deuxième partie, intitulée Ce que cela signifie pour nous, traduit ces insights en implications stratégiques concrètes pour l’entreprise. La troisième partie, intitulée Ce que nous devons décider, formule deux ou trois questions décisionnelles précises que la direction doit trancher.

Contraintes : aucun jargon statistique, aucune mention de méthodologie, aucun chiffre sans unité ni contexte comparatif. Le ton est celui d’un conseiller stratégique qui parle à un pair intelligent mais pressé.

---

Domaine 3 — Éducation et Pédagogie

La promesse de la personnalisation

L’éducation est peut-être le domaine où le potentiel transformatif des LLM est le plus profond. Depuis des décennies, les pédagogues savent que l’enseignement le plus efficace est celui qui s’adapte à l’apprenant — son niveau, son style d’apprentissage, ses centres d’intérêt, ses blocages spécifiques. Mais dans un système éducatif où un enseignant fait face à trente élèves simultanément, cette personnalisation est structurellement impossible à plein régime.

Les LLM bien promptés peuvent la rendre accessible. Non pas pour remplacer l’enseignant — la relation humaine, l’encouragement, la lecture des émotions en classe sont irremplaçables — mais pour produire à la demande des explications personnalisées, des exercices adaptés, des analogies taillées sur mesure pour chaque profil d’apprenant.

Cas 1 — Expliquer un concept en adaptant au profil de l’apprenant

Le besoin. Vous êtes professeur de sciences économiques et sociales. Vous devez expliquer le concept de taux directeur de banque centrale à une classe hétérogène. Vous voulez préparer plusieurs versions de l’explication — l’une très accessible pour les élèves en difficulté, l’une standard pour le niveau moyen de la classe, l’une enrichie pour les élèves avancés qui peuvent aller plus loin.

Le prompt.

Tu es un professeur de sciences économiques et sociales expérimenté, reconnu pour ta capacité à rendre accessibles des concepts abstraits grâce à des analogies du quotidien. Tu t’adresses à des lycéens de terminale.

Concept à expliquer : le rôle du taux directeur d’une banque centrale dans le contrôle de l’inflation.

Produis trois versions de cette explication, de complexité croissante.

Version 1 — Accessible : pour un élève qui a du mal avec les concepts abstraits et a besoin d’une analogie concrète et d’un vocabulaire très simple. Maximum six phrases. Aucun terme technique sans définition immédiate.

Version 2 — Standard : pour un élève de niveau moyen qui comprend les mécanismes économiques de base mais n’a jamais été exposé à la politique monétaire. Longueur libre, structure libre, mais doit inclure un exemple chiffré simple.

Version 3 — Avancée : pour un élève très à l’aise qui veut comprendre les nuances et les limites de cet outil. Peut introduire des concepts comme les anticipations inflationnistes ou l’effet sur les taux de change. Peut mentionner des situations historiques réelles. Longueur libre.

Pour chaque version, termine par une question de vérification de compréhension adaptée au niveau.

La valeur pédagogique de ce prompt. La granularité des trois niveaux permet à l’enseignant d’adapter sa communication selon l’élève devant lui, sans avoir à recréer l’explication de zéro à chaque fois. Les questions de vérification intégrées permettent d’évaluer immédiatement la compréhension et d’identifier si une version plus accessible ou plus avancée est nécessaire.

---

Cas 2 — Créer un exercice différencié

Le besoin. Vous enseignez la rédaction argumentative à des étudiants de première année de licence. Vous voulez créer un exercice qui entraîne la même compétence — construire un argument avec thèse, antithèse et synthèse — mais sur des sujets différents selon les centres d’intérêt des étudiants.

Le prompt.

Tu es un enseignant en expression écrite et communication pour l’enseignement supérieur. Tu crées des exercices pédagogiques engageants qui développent la rigueur argumentative.

Compétence visée : rédiger un texte argumentatif structuré en thèse, antithèse, synthèse sur un sujet qui prête à débat.

Crée cinq variantes de cet exercice, chacune sur un sujet différent, pour les profils d’étudiants suivants : étudiant passionné de sport, étudiant intéressé par la technologie et le numérique, étudiant engagé sur les enjeux environnementaux, étudiant fan de culture pop et de séries, et étudiant intéressé par l’économie et l’entrepreneuriat.

Pour chaque variante, fournis : le sujet exact sous forme de question ouverte, une phrase d’accroche pour introduire le sujet en classe et susciter l’intérêt, deux arguments pour la thèse et deux pour l’antithèse que l’étudiant peut développer, et un critère d’évaluation spécifique à ce sujet — ce qui constituerait une synthèse particulièrement réussie dans ce contexte précis.

Les cinq sujets doivent être de difficulté comparable et se prêter tous à un vrai débat — évite les sujets dont la réponse est évidente ou moralement tranchée.

---

Cas 3 — Générer un feedback personnalisé sur une copie

Le besoin. Vous avez trente copies à corriger. Vous voulez fournir un feedback vraiment utile à chaque étudiant — pas juste une note et deux lignes génériques — mais vous n’avez pas le temps de rédiger deux cents mots de commentaires personnalisés pour chacune.

Le prompt.

Tu es un enseignant bienveillant et exigeant en rédaction académique. Tu crois que le feedback est le principal levier de progression et tu sais formuler des commentaires qui motivent autant qu’ils orientent.

Voici la copie d’un étudiant et les critères d’évaluation de l’exercice :

Critères : [liste des critères avec leurs poids]

Copie : [texte de la copie]

Produis un feedback structuré en quatre parties. Première partie — Ce qui fonctionne bien : identifie deux ou trois éléments spécifiques réussis, en citant des passages précis de la copie et en expliquant pourquoi ils fonctionnent. Sois précis — “ta structure est claire” est un compliment inutile, “ton argument en paragraphe trois est particulièrement convaincant parce qu’il anticipe l’objection principale” est un feedback formateur.

Deuxième partie — Le point de progrès prioritaire : identifie le problème le plus fondamental qui limite la qualité de ce travail. Un seul, pas trois. Explique le mécanisme du problème et comment il affecte la réception du texte.

Troisième partie — Une action concrète : propose une révision précise d’un passage spécifique pour illustrer le point de progrès. Ne récris pas la copie — montre comment un seul endroit pourrait être amélioré et pourquoi.

Quatrième partie — Une question ouverte : termine par une question qui pousse l’étudiant à réfléchir lui-même à son texte et à son développement, sans lui donner la réponse.

Ton : direct, chaleureux, jamais condescendant. L’objectif est que l’étudiant ait envie de progresser, pas qu’il se sente jugé.

---

Domaine 4 — Développement logiciel

Le développeur augmenté

Le développement logiciel est l’un des domaines où l’adoption des LLM a été la plus rapide et la plus massive. Des outils comme GitHub Copilot ont normalisé l’assistance IA dans le flux de travail quotidien des développeurs. Mais la plupart des développeurs n’exploitent qu’une fraction du potentiel disponible — ils utilisent les LLM pour compléter du code, rarement pour les tâches à plus haute valeur ajoutée comme la revue critique, la conception architecturale, la documentation ou la détection d’erreurs logiques.

Ce que le prompt engineering apporte ici, c’est la capacité d’utiliser les LLM non seulement comme autocomplete avancé, mais comme partenaire de réflexion technique.

Cas 1 — La revue de code constructive

Le besoin. Vous avez écrit une fonction Python qui fonctionne mais que vous suspectez d’avoir des problèmes de lisibilité, de robustesse ou de performance. Vous voulez un regard externe critique mais constructif.

Le prompt.

Tu es un développeur Python senior avec une expertise particulière en clean code, en principes SOLID et en bonnes pratiques de développement en équipe. Tu fais des revues de code constructives — tu identifies les vrais problèmes, pas les préférences stylistiques subjectives, et tu expliques toujours pourquoi un problème en est un.

Contexte de ce code : il s’agit d’une fonction qui [description de la fonction et de son rôle dans l’application]. Elle sera maintenue par une équipe de quatre développeurs de niveaux variés. Les priorités sont dans cet ordre : lisibilité et maintenabilité, robustesse, et performance.

Voici le code : [code à revoir]

Réalise une revue structurée en quatre sections.

Section 1 — Problèmes critiques : les éléments qui doivent absolument être corrigés avant toute mise en production, avec une explication du risque concret qu’ils font peser.

Section 2 — Améliorations importantes : les éléments qui ne bloquent pas la mise en production mais qui devraient être adressés rapidement, avec une justification basée sur les priorités que j’ai données.

Section 3 — Suggestions mineures : des améliorations optionnelles qui rendraient le code plus élégant ou plus idiomatique, clairement marquées comme non prioritaires.

Section 4 — Ce qui est bien fait : deux ou trois éléments spécifiques qui sont correctement implémentés et qu’il ne faut pas modifier.

Pour les deux premières sections, propose une version corrigée du code concerné avec un commentaire explicatif sur la correction apportée.

Pourquoi cette structure fonctionne. La séparation en niveaux de criticité permet au développeur de prioriser son travail de correction. L’ancrage dans les priorités explicites — lisibilité avant performance — évite que le modèle donne des conseils génériques qui ne correspondent pas aux contraintes réelles du projet. La section “Ce qui est bien fait” évite le biais de la revue purement négative et fournit des points d’ancrage positifs pour le développeur junior.

---

Cas 2 — Conception architecturale assistée

Le besoin. Vous démarrez un nouveau projet et vous devez choisir une architecture. Vous avez une idée mais vous voulez challenger votre approche avant de vous engager.

Le prompt.

Trois architectes logiciels seniors analysent ce problème de conception depuis leurs perspectives respectives, puis délibèrent et aboutissent à une recommandation commune.

Architecte 1 — spécialiste de la simplicité et de la maintenabilité : il défend toujours l’approche la plus simple qui satisfait les besoins actuels, méfiant des abstractions prématurées et de la complexité inutile.

Architecte 2 — spécialiste de la scalabilité et de l’évolutivité : il pense toujours à la façon dont le système devra évoluer dans dix-huit à trente-six mois et anticipe les contraintes de charge.

Architecte 3 — spécialiste de la robustesse et de la sécurité : il évalue chaque décision architecturale sous l’angle de la tolérance aux pannes, de la gestion des erreurs et des vecteurs d’attaque.

Le projet : [description du projet, des contraintes techniques, de l’équipe, du délai et du budget]

L’approche architecturale envisagée : [votre proposition]

Chaque architecte expose ses arguments — ce qui lui plaît dans cette approche, ce qui le préoccupe, et ce qu’il modifierait. Puis les trois convergent vers une recommandation finale qui intègre les meilleures idées de chacun et explicite clairement les compromis acceptés.

C’est un Tree-of-Thought appliqué à la conception technique. La délibération entre trois perspectives de valeurs différentes produit une analyse bien plus complète qu’un prompt classique, et les compromis explicités à la fin sont exactement ce dont un développeur a besoin pour prendre une décision éclairée et l’expliquer à son équipe.

---

Cas 3 — Générer une documentation de qualité

Le besoin. Votre code fonctionne. Votre documentation est inexistante ou insuffisante. Vous devez produire une documentation technique complète qui sera utile à la fois pour les développeurs qui maintiennent le code et pour ceux qui l’intègrent dans d’autres systèmes.

Le prompt.

Tu es un technical writer avec une forte culture développeur — tu as toi-même codé pendant dix ans avant de te spécialiser dans la documentation. Tu sais produire une documentation qui répond aux vraies questions des développeurs, dans l’ordre où ils les posent.

Voici le code à documenter : [code]

Produis une documentation complète en quatre parties.

Partie 1 — Vue d’ensemble : en deux paragraphes, explique ce que fait ce module, le problème qu’il résout, et dans quel contexte l’utiliser. Écris comme si tu expliquais à un développeur compétent qui découvre ce code pour la première fois.

Partie 2 — Référence API : pour chaque fonction publique, documente le nom, le rôle en une phrase, les paramètres avec leur type et leur description, la valeur de retour avec son type, les exceptions pouvant être levées, et un exemple d’utilisation minimal.

Partie 3 — Guide d’utilisation : un exemple complet de bout en bout qui montre le cas d’usage principal, avec des commentaires inline qui expliquent les décisions importantes.

Partie 4 — Pièges et cas limites : liste les trois ou quatre erreurs les plus fréquentes que les développeurs font avec ce code, et comment les éviter. Sois spécifique — “ne pas gérer les erreurs” n’est pas utile, “ne pas vérifier que le paramètre X n’est pas None avant d’appeler la méthode Y causera une AttributeError silencieuse dans les environnements de production” l’est.

---

Ce que vous emportez avec vous

Vous avez traversé six domaines, douze cas d’usage, et des dizaines de choix de formulation commentés. Mais ce qui compte, ce n’est pas la mémorisation de ces exemples. C’est la façon de penser qu’ils illustrent.

Avant chaque prompt, vous vous posez maintenant les bonnes questions. Quel est le rôle le plus pertinent pour cette tâche ? Quel contexte le modèle ne peut-il pas deviner et dont il a besoin pour être précis ? Quel format de sortie correspond à l’usage que je vais faire de ce résultat ? Est-ce une tâche linéaire ou une tâche qui mérite d’être vue depuis plusieurs angles ? Est-ce assez simple pour tenir dans un prompt ou assez complexe pour mériter une chaîne ? Qu’est-ce qui pourrait produire des hallucinations ici et comment l’anticiper ?

Ces questions, posées systématiquement et rapidement, sont ce qui distingue l’utilisateur occasionnel du prompt engineer accompli. Elles ne ralentissent pas votre travail — avec la pratique, elles prennent quelques secondes. Et ce qu’elles vous font gagner en qualité de résultat est sans commune mesure avec l’effort qu’elles demandent.

---

Un dernier mot : la bibliothèque vivante

La compétence la plus durable que vous pouvez développer à partir d’aujourd’hui est la constitution d’une bibliothèque personnelle de prompts. Chaque fois que vous construisez un prompt qui produit un résultat remarquable, documentez-le. Notez la tâche, le contexte, la version finale du prompt, et ce qui a rendu le résultat satisfaisant.

Avec le temps — quelques semaines suffisent — vous accumulerez un capital de prompts éprouvés couvrant les situations les plus fréquentes de votre vie professionnelle. Ce capital est réutilisable, adaptable, et transmissible à vos collaborateurs. C’est l’une des formes les plus concrètes de ce que les professionnels appellent l’intelligence organisationnelle — la connaissance qui ne repart pas avec l’individu mais reste dans l’organisation.

Les modèles vont continuer à évoluer. Les interfaces vont changer. Les usages vont se diversifier. Mais la compétence fondamentale que vous avez développée dans ce cours — penser clairement, formuler précisément, itérer méthodiquement — est celle qui restera pertinente quelle que soit l’évolution technologique. Parce que c’est, au fond, la compétence de communiquer avec intention.

Et ça, aucun modèle ne peut vous l’enlever.