Tu as compris qu'une demande précise vaut mille fois mieux qu'un souhait vague. Très bien. Mais là, une nouvelle frustration t'attend, et elle est plus subtile. Tu fais un effort, tu écris une demande que tu crois précise, et le résultat n'est toujours pas tout à fait ça. Pas mauvais, mais pas juste. Comme un vêtement presque à ta taille, qui serre un peu à un endroit et flotte à un autre. Tu ne comprends pas: tu as pourtant été clair, non.

Prenons un cas vécu par beaucoup. Une personne qui gère un petit institut de bien-être écrit: "écris une présentation de mon institut, quatre phrases, ton doux, pour ma page d'accueil". C'est une bonne demande, honnêtement. Objectif nommé, longueur précisée, ton indiqué, destinataire implicite. Et pourtant la réponse tombe à côté: elle parle de "votre havre de paix au coeur de la ville", alors que l'institut est en pleine campagne, elle vante "une équipe de dix experts" alors qu'elle travaille seule, elle invente une ambiance zen japonaise qui n'a rien à voir avec sa déco chaleureuse et rustique.

La machine n'a pas été bête. Elle a fait de son mieux avec ce qu'elle avait, et ce qu'elle avait était incomplet. On lui a dit quoi faire et comment le dire, mais pas qui elle devait être, ni ce qu'elle devait savoir, ni sous quelle forme exacte rendre son travail. Elle a comblé les vides avec des clichés de brochure, parce que c'est ce qu'elle a vu mille fois.

C'est là qu'intervient la grande révélation de ce sous-module. Un bon prompt n'est pas juste une phrase précise, c'est un assemblage de briques. Comme une maison a besoin de fondations, de murs, d'un toit, un prompt solide a besoin de plusieurs éléments qui, ensemble, tiennent debout. Enlève une brique et ça penche. Une fois que tu connais ces briques, tu ne les oublies plus, et tes demandes cessent de "tomber à côté". Tu vas voir, elles sont peu nombreuses, faciles à retenir, et tu les as déjà toutes croisées sans les nommer.

Connaitre les briques d'un bon prompt, ce n'est pas devenir un expert technique, c'est arrêter de tâtonner. Tant que tu improvises, tu obtiens des résultats en dents de scie: parfois bons par chance, souvent décevants sans savoir pourquoi. Avec les briques en tête, tu as une liste mentale que tu déroules, et tes résultats deviennent réguliers. La régularité, c'est ce qui te fait passer de "je tente l'IA de temps en temps" à "je m'appuie dessus tous les jours".

Le premier bénéfice est un gain de justesse. Quand tu donnes un rôle, du contexte, une tâche et un format, la machine n'a presque plus de trous à combler. Elle ne peut plus inventer une équipe de dix personnes ou une ambiance qui n'existe pas, parce que tu as posé les faits. Les résultats collent à ta réalité, et tu passes beaucoup moins de temps à corriger.

Le deuxième bénéfice est la confiance. Beaucoup de débutants ont peur de "mal parler à l'IA", comme s'il fallait connaitre une formule magique. Il n'y a pas de formule secrète, il y a juste des briques. Une fois que tu sais qu'il t'en faut quatre ou cinq, l'angoisse tombe. Tu n'es plus devant une page blanche intimidante, tu remplis des cases: qui, quoi sais-je, quoi faire, sous quelle forme. C'est rassurant, presque mécanique, et ça libère l'esprit.

Le troisième bénéfice est la réutilisation. Un prompt bien construit avec ses briques devient un outil que tu gardes. Tu l'écris une fois pour "annoncer une promotion", et le mois suivant tu changes juste les faits, tu gardes la structure. Tu te constitues petit à petit une boite à modèles personnels. C'est exactement ainsi que travaillent les gens efficaces: ils ne réinventent pas la demande à chaque fois, ils adaptent une structure éprouvée.

Enfin, comprendre les briques te prépare à tout le reste de ton apprentissage. Plus tard, tu entendras parler d'agents, d'outils, de systèmes qui font des choses complexes. Or tous reposent sur le même squelette: un rôle, un contexte, une tâche, un format. Ce que tu apprends ici en petit, pour un simple message, est exactement ce qui fait tourner les systèmes les plus avancés de MogaCode. Tu n'apprends pas une astuce jetable, tu apprends la grammaire de base de toute conversation avec une machine intelligente.

Voici les briques d'un bon prompt. Retiens-les dans l'ordre, c'est plus facile: qui, ce qu'il faut savoir, quoi faire, sous quelle forme. Quatre questions, et ta demande tient debout. Prenons-les une par une.

1. Le rôle: dis à l'IA qui elle doit être

C'est la brique la plus surprenante pour les débutants, et l'une des plus efficaces. Avant même de dire ce que tu veux, tu peux dire à la machine quel personnage endosser. "Tu es un conseiller commercial expérimenté et bienveillant". "Tu es un correcteur rigoureux qui traque les fautes". "Tu es un ami qui m'explique les choses simplement, sans jargon". En donnant un rôle, tu orientes d'un coup le ton, le vocabulaire et le point de vue de toute la réponse.

Un exemple parlant. Demande "explique-moi les avis clients sur Google", puis recommence avec "tu es un commerçant qui a mis dix ans à comprendre l'importance des avis, explique-moi ça comme à un débutant". La deuxième réponse sera plus humaine, plus concrète, remplie de vécu, parce que tu as donné un rôle qui porte une expérience.

2. Le contexte: donne-lui ce qu'elle ne peut pas deviner

La machine ne connait ni ton métier, ni ta ville, ni ta clientèle, ni ton histoire. Tout ce qu'elle ignore, elle l'invente. Alors nourris-la de faits vrais. Où es-tu, que vends-tu, qui sont tes clients, qu'est-ce qui te distingue, y a-t-il quelque chose à éviter absolument. Le contexte, c'est la différence entre une réponse qui parle de toi et une réponse qui parle d'un commerce imaginaire.

Reprends l'institut de bien-être. En ajoutant "je travaille seule, en pleine campagne, dans une ancienne ferme rénovée avec une déco chaleureuse en bois", tu empêches d'un coup tous les clichés de havre urbain et d'équipe nombreuse. La machine s'appuie sur du réel au lieu de meubler.

3. La tâche: dis exactement quoi faire

C'est le coeur, et c'est ce que tu as appris au sous-module précédent: un verbe clair et un objectif net. "Écris", "résume", "corrige", "liste", "compare", "traduis". Un seul travail à la fois, bien défini. Évite d'empiler cinq demandes dans une seule phrase, car la machine en oubliera. Si tu as plusieurs choses à faire, fais-les l'une après l'autre.

Par exemple, ne dis pas "écris une présentation et aussi trois idées de publications et corrige mon ancien texte". Sépare: d'abord la présentation, ensuite les idées, ensuite la correction. Chaque tâche isolée est mieux exécutée. C'est comme confier un travail à quelqu'un: une consigne claire à la fois vaut mieux qu'une avalanche.

4. Le format de sortie: dis sous quelle forme tu veux la réponse

C'est la brique qu'on oublie le plus, et elle fait gagner un temps fou. Veux-tu une liste ou un paragraphe. Trois points ou dix. Un tableau. Un message prêt à copier. Des phrases courtes. Si tu ne dis rien, la machine choisit pour toi, souvent un gros pavé que tu devras découper. En précisant le format, tu reçois un résultat directement utilisable.

Concrètement, "donne-moi cinq idées, sous forme de liste, une phrase chacune, sans introduction ni conclusion" te renverra exactement ça, propre, prêt à l'emploi. Ajoute ici tes contraintes: la longueur, les mots à éviter, la langue, tout ce qui cadre la forme finale.

En résumé: un bon prompt assemble quatre briques, le rôle (qui elle est), le contexte (ce qu'elle doit savoir), la tâche (quoi faire) et le format (sous quelle forme). Pose ces quatre questions et ta demande cesse de tomber à côté.

Chez MogaCode, il y a une boite à outils très particulière pour le référencement, celle qu'on appelle gsc-connect. Elle n'a rien d'une baguette magique. C'est un ensemble de dizaines d'outils, chacun avec un nom précis et un travail précis. Il y en a un qui mesure les positions d'un site sur Google, un autre qui inspecte la vitesse d'une page, un autre qui repère les pages oubliées d'un site, un autre qui regarde ce que font les concurrents. Chaque outil fait une seule chose, mais il la fait bien, et il porte un nom clair qui dit ce qu'il fait.

Ce qui est fascinant, et directement lié à notre leçon, c'est comment une IA se sert de cette boite. On ne dit pas à l'IA "améliore le référencement", ce serait le souhait vague qu'on a banni. On lui donne un rôle ("tu es une assistante SEO qui s'appuie uniquement sur des données réelles"), un contexte (le site concerné, la ville visée, le métier), une tâche claire, et surtout on lui met à disposition des outils aux noms explicites. L'IA lit la situation, puis choisit le bon outil par son nom, exactement comme un mécanicien choisit la bonne clé dans sa caisse. Elle appelle l'outil qui mesure les positions, lit le résultat réel, puis appelle l'outil suivant.

Regarde bien le parallèle avec les quatre briques. Le rôle est donné. Le contexte est donné. La tâche est nette. Et le format de sortie, c'est justement la précision des outils: chacun renvoie une information dans une forme définie, pas un pavé flou. Cette boite à outils est, en réalité, l'illustration grandeur nature de tout ce sous-module. Quand chaque brique est en place, une IA peut enchainer des dizaines d'actions précises sans se perdre.

Il y a une leçon supplémentaire, presque philosophique. La force de gsc-connect ne vient pas d'une intelligence surhumaine, elle vient du découpage en outils clairs et bien nommés. Un gros outil vague qui "ferait tout" serait ingérable et donnerait n'importe quoi. Des dizaines de petits outils précis, chacun avec sa mission, donnent un système fiable. C'est exactement le principe des briques: mieux vaut plusieurs éléments clairs et séparés qu'un seul bloc confus.

Ce que tu peux en retenir pour tes propres demandes: nomme les choses précisément, sépare les tâches, donne à chaque demande une forme attendue. Tu n'as pas des dizaines d'outils, mais tu as la même logique à ta disposition. Quand tu construis un prompt brique par brique, tu fais, à ton échelle, ce que fait cette machine de guerre du référencement: tu transformes une intention floue en une suite d'instructions claires que la machine peut exécuter sans se tromper.

Voici l'erreur classique, celle qui gâche même les demandes bien intentionnées: oublier la brique du contexte, et laisser la machine inventer. Un artisan chauffagiste, content de progresser, écrit une demande soignée: "tu es un rédacteur professionnel, écris-moi une page de présentation de mon activité, ton sérieux et rassurant, en un paragraphe de six phrases". Rôle, tâche, ton, format: presque tout y est. Il appuie, satisfait.

La réponse arrive, bien tournée, et pourtant inutilisable. Elle affirme qu'il intervient "sept jours sur sept, vingt-quatre heures sur vingt-quatre", ce qui est faux, il ne fait pas les urgences de nuit. Elle parle d'une "équipe de techniciens certifiés", alors qu'il travaille seul avec un apprenti. Elle mentionne "plus de vingt ans d'expérience", un chiffre sorti de nulle part. S'il publie ça, il ment à ses clients sans même l'avoir voulu, et le jour où quelqu'un appelle à deux heures du matin en croyant à la promesse, la déception sera brutale.

Que s'est-il passé. Il manquait la brique la plus importante pour la vérité: le contexte réel. La machine a rempli les vides avec ce qui "fait pro" en général, c'est à dire des promesses standard de site de chauffagiste. Elle n'a pas menti par malice, elle a comblé un manque d'information par des clichés. Sans faits, une IA fabrique du plausible, et le plausible n'est pas le vrai.

Cette mésaventure résonne avec une règle profonde chez MogaCode: jamais de données inventées, jamais de chiffre sorti de nulle part. Quand une information réelle manque, on le dit et on s'arrête, on ne devine pas. C'est vrai pour les systèmes de MogaCode, ça doit devenir vrai pour toi. Si tu ne donnes pas tes vrais horaires, ta vraie taille d'équipe, ta vraie ancienneté, la machine les inventera, et tu porteras la responsabilité de ce mensonge une fois publié.

La correction est simple et tient en une brique ajoutée. L'artisan aurait dû écrire: "je travaille seul avec un apprenti, sans urgences de nuit, sur la région de Namur, spécialisé dans l'entretien de chaudières, sans inventer aucun chiffre que je ne t'ai pas donné". Cette dernière consigne, "n'invente aucun chiffre", est un garde-fou précieux à connaitre dès tes premiers prompts. La leçon: une demande peut être bien structurée et quand même dangereuse si elle laisse la machine remplir les vides. Le contexte n'est pas une brique optionnelle, c'est le rempart contre l'invention.

• Le prompt sans rôle. Symptôme: le ton n'est jamais tout à fait juste. Cause: tu n'as pas dit à l'IA qui elle devait être, elle prend une voix neutre passe-partout. Réflexe: commence par "tu es..." pour orienter d'emblée le ton et le point de vue.
• Le contexte manquant. Symptôme: la réponse invente des faits sur toi (équipe, horaires, ancienneté). Cause: la machine comble ce qu'elle ignore avec des clichés plausibles. Réflexe: donne les faits réels et ajoute "n'invente aucune information que je ne t'ai pas donnée".
• La tâche empilée. Symptôme: la machine oublie une partie de ta demande. Cause: tu as mis trois ou quatre travaux dans une seule phrase. Réflexe: une tâche à la fois, l'une après l'autre.
• Le format oublié. Symptôme: tu reçois un gros pavé que tu dois découper toi-même. Cause: tu n'as pas dit sous quelle forme tu voulais la réponse. Réflexe: précise liste ou paragraphe, nombre de points, longueur, prêt à copier.
• Le plausible pris pour du vrai. Symptôme: un chiffre ou un détail sonne bien et tu le gardes sans vérifier. Cause: l'IA produit du crédible même quand elle ne sait pas. Réflexe: vérifie tout fait que tu n'as pas toi-même fourni, ne publie jamais un chiffre inventé.

Voici une croyance qui bloque des milliers de débutants, et il faut la briser tout de suite. Beaucoup pensent qu'un bon prompt doit sortir parfait du premier coup, comme un tir au but réussi. Alors ils s'acharnent à écrire la demande idéale, la relisent dix fois, et quand la réponse n'est pas parfaite, ils concluent qu'ils ont échoué, ou que l'IA est décevante. Ils ferment la fenêtre, frustrés, persuadés de ne pas être doués.

La vérité est tout autre, et elle va te soulager: personne n'écrit le prompt parfait du premier coup, pas même les gens qui font ça toute la journée. Parler à une IA, ce n'est pas tirer un penalty, c'est avoir une conversation. Et une conversation, ça se construit à plusieurs échanges. Tu demandes, tu regardes ce qui vient, tu ajustes, tu redemandes. C'est normal, c'est même le coeur du métier.

Imagine que tu confies un travail à quelqu'un de nouveau dans ton équipe. La première fois, il te rend quelque chose de correct mais pas tout à fait ça. Tu ne le renvoies pas en le traitant d'incapable. Tu lui dis: "c'est bien, mais le début est trop long, et tu as oublié de mentionner nos horaires". Il corrige, et la deuxième version est bien meilleure. Avec une IA, c'est identique, sauf qu'elle ne se vexe jamais, ne se fatigue jamais, et corrige en trois secondes.

Le déclic de ce dernier sous-module de fondations, c'est de comprendre que la puissance ne vient pas d'un prompt magique, mais de l'échange. Un prompt moyen suivi de deux bonnes corrections bat toujours un prompt "parfait" écrit dans l'angoisse. Tu vas apprendre à lire une réponse pour repérer ce qui cloche, à corriger un point à la fois, à garder ce qui marche, et à savoir quand il vaut mieux repartir de zéro. Ce n'est pas une compétence de plus, c'est la compétence qui rend toutes les autres tolérantes à l'erreur. Tu as le droit de te tromper dans ta demande, parce que tu sais maintenant que tu pourras rattraper en discutant.

Savoir itérer change ton rapport entier à l'IA, et même ton rapport à l'erreur. Le premier effet, c'est la fin de la pression. Tant que tu crois devoir réussir du premier coup, chaque demande est un test stressant. Dès que tu sais que tu vas ajuster en plusieurs fois, tu te lances plus facilement, tu oses, tu expérimentes. Cette décontraction est précieuse: les gens qui progressent le plus vite sont ceux qui tentent beaucoup, pas ceux qui réfléchissent trop avant de taper.

Le deuxième effet, c'est une qualité finale bien supérieure. Une réponse retravaillée en deux ou trois échanges est presque toujours meilleure qu'une réponse unique, aussi bonne soit-elle. Parce qu'en discutant, tu affines ta propre idée de ce que tu veux. Souvent, tu ne sais pas exactement ce que tu cherches avant de voir une première version qui ne te convient pas. La première réponse sert de brouillon qui révèle tes vrais critères. "Ah non, pas ce ton là", "tiens, ça oui, mais en plus court". La conversation te fait accoucher de ta demande réelle.

Le troisième effet, c'est l'économie d'énergie mentale. Corriger un point à la fois est bien plus reposant que d'essayer de tout prévoir dans une demande géante et parfaite. Tu avances par petites touches, comme un peintre qui recule, regarde, ajoute une touche, recule encore. C'est plus humain, plus naturel, et paradoxalement plus rapide, parce que tu ne te noies pas dans une consigne monstre impossible à écrire.

Le quatrième effet touche à la fiabilité. En itérant, tu vérifies. Tu lis vraiment ce que la machine a produit, tu repères une erreur, une invention, une maladresse, et tu la corriges avant qu'elle ne parte dans le monde. L'itération est ta dernière porte de qualité avant publication. Les gens qui ne relisent pas et copient la première réponse sont ceux qui publient des bêtises. Ceux qui discutent avec la machine attrapent les problèmes à temps.

Enfin, itérer, c'est apprendre. Chaque correction t'enseigne quelque chose sur la manière dont la machine réagit. Tu remarques quel type de consigne marche, laquelle est mal comprise. Au fil des semaines, sans t'en rendre compte, tu deviens meilleur, non pas parce que tu as mémorisé des formules, mais parce que tu as pratiqué la conversation. C'est la fondation qui te portera vers tout le reste de ton parcours.

Itérer n'est pas taper "fais mieux" en boucle, ça, tu l'as déjà vu, ça ne mène nulle part. C'est une méthode douce en quatre gestes qui transforme un échange décevant en résultat solide.

1. Lis vraiment la réponse avant de réagir

Le premier réflexe, avant même de corriger, c'est de lire attentivement ce que la machine a produit. Pas en diagonale, vraiment. Repère précisément ce qui va et ce qui ne va pas. Est-ce le ton, la longueur, un fait inventé, un passage hors sujet, un mot mal choisi. Tant que tu ne sais pas nommer ce qui cloche, tu ne peux pas le corriger. La plupart des "fais mieux" ratés viennent de là: on sent que ce n'est pas ça, mais on ne prend pas trois secondes pour dire pourquoi.

Par exemple, au lieu de "bof, recommence", dis-toi: "le contenu est bon, mais le deuxième paragraphe répète le premier, et la fin est trop commerciale". Tu viens de transformer un vague malaise en deux corrections précises.

2. Corrige un point à la fois, précisément

Une fois que tu sais ce qui cloche, ne balance pas dix reproches d'un coup. Vas-y par touches claires. "Raccourcis le deuxième paragraphe de moitié". "Enlève la dernière phrase, elle fait trop pub". "Remplace le mot chaleureux par accueillant, il revient trop souvent". La machine garde le reste et applique ta correction. C'est chirurgical, et tu gardes la maitrise.

Un exemple: tu as un bon message mais il commence mal. Dis "garde tout, mais réécris seulement la première phrase pour qu'elle accroche davantage". Tu ne jettes pas le travail, tu le retouches là où il faut.

3. Garde ce qui marche, dis ce qui cloche

C'est le geste le plus important et le plus oublié. Quand tu corriges, dis toujours ce que tu veux conserver, pas seulement ce que tu veux changer. Sinon, en corrigeant un défaut, la machine risque de casser ce qui était déjà bien. Formule tes corrections comme un cadrage: "j'aime le ton et la longueur, garde-les, change juste l'exemple à la fin". Tu protèges les bonnes parties.

Concrètement, si la troisième version était presque parfaite sauf un détail, ne repars pas d'une consigne neuve. Dis "reprends exactement la version précédente et change uniquement ceci". Tu construis sur l'acquis au lieu de tout recommencer.

4. Sache quand repartir de zéro

Parfois, la conversation part dans une mauvaise direction et s'enlise. Les corrections s'accumulent, la machine s'emmêle, chaque version est bancale d'une nouvelle façon. Quand tu sens cet enlisement, ne t'acharne pas. Recommence proprement, avec une demande neuve enrichie de tout ce que tu as appris pendant l'échange raté. Tu ne perds rien: l'échange manqué t'a montré ce que tu ne voulais pas, et ça, c'est de l'information précieuse pour ton nouveau départ.

Par exemple, après cinq corrections qui tournent en rond, ouvre une nouvelle demande: "écris un message court, ton accueillant, sans formule commerciale, en mentionnant mes horaires réels que voici". Tu as intégré les leçons de l'échec dans une base propre.

En résumé: itérer, c'est lire vraiment la réponse, corriger un point à la fois, protéger ce qui marche, et savoir repartir de zéro quand ça s'enlise. La conversation, pas le prompt parfait, fait la qualité.

Chez MogaCode, il y a un assistant sur WhatsApp qui rend un service très concret. Il dispose de deux capacités bien distinctes, deux outils qu'on peut résumer par deux verbes: "lire" et "envoyer". L'outil "lire" lui permet de consulter des messages. L'outil "envoyer" lui permet de transmettre un message. Deux actions séparées, volontairement, et c'est là que se cache une leçon magnifique sur l'itération et la prudence.

Pourquoi séparer ainsi. Parce que lire et envoyer n'ont pas du tout le même poids. Lire, c'est réversible, sans conséquence: on peut relire cent fois, il ne se passe rien de grave. Envoyer, c'est irréversible: une fois qu'un message est parti chez quelqu'un, on ne peut plus le rattraper. En séparant les deux outils, on crée un point d'arrêt naturel entre "préparer" et "agir". L'assistant peut lire, comprendre, préparer un brouillon, et l'envoi reste un acte à part, contrôlé, jamais fait à la légère.

Fais le lien avec ta manière d'itérer. Quand tu discutes avec une IA pour écrire un message, tu es exactement dans la phase "lire et préparer". Tu affines, tu corriges, tu retravailles, autant de fois que tu veux, sans risque. C'est réversible, c'est ton brouillon. Le moment "envoyer", lui, doit rester un acte séparé et conscient: tu ne copies pas la réponse pour l'envoyer aussitôt, tu la relis une dernière fois, tu vérifies, et seulement alors tu la transmets. L'assistant WhatsApp de MogaCode t'enseigne, par sa conception même, à ne jamais confondre le brouillon et l'envoi.

Il y a une deuxième leçon, sur la clarté des outils. "Lire" et "envoyer" sont des noms limpides. Chacun sait exactement ce que fait l'assistant quand il utilise l'un ou l'autre. Cette transparence est rassurante et évite les mauvaises surprises. De la même façon, quand tu itères, sois clair avec toi-même sur ce que tu fais à chaque étape: "là je prépare", "là je corrige", "là je valide", "là j'envoie". Nommer l'étape où tu en es t'évite de publier un brouillon par erreur.

Ce cas t'apprend, au fond, que l'itération n'est pas seulement une question de qualité, c'est aussi une question de sécurité. On travaille tranquillement dans la zone réversible, on corrige autant qu'il faut, et on garde l'action irréversible pour la toute fin, en pleine conscience. Un système bien conçu met une barrière entre les deux. Toi, à ta petite échelle, tu peux mettre la même barrière: itère librement, mais fais de l'envoi un geste à part, jamais automatique.

Garde en tête, en écrivant tes premiers prompts, que la clarté n'est jamais du temps perdu : chaque précision que tu ajoutes en amont (le rôle, le contexte, le format attendu) t'épargne plusieurs allers-retours de correction en aval. Un prompt un peu plus long mais net vaut toujours mieux qu'une demande courte et floue que tu devras relancer trois fois. La précision, c'est de la vitesse, pas de la lenteur.

Voici une leçon que MogaCode a apprise à ses dépens, et qui parle d'itération d'une façon inattendue. Il fut un temps où certaines tâches importantes étaient programmées pour se lancer automatiquement depuis un ordinateur de bureau, un mac. L'idée semblait pratique: la machine s'occupe de tout, on n'y pense plus. Sauf qu'un jour, l'ordinateur était éteint au moment prévu. La tâche ne s'est pas lancée. Elle a été purement et simplement ratée, sans avertissement, sans rattrapage. Personne ne s'en est rendu compte immédiatement, parce qu'on faisait confiance à un automatisme qu'on ne surveillait plus.

La leçon tirée fut nette: on a déplacé ces tâches sur un serveur souverain, une machine de MogaCode qui reste allumée en permanence, fiable, sous contrôle. Depuis, l'automatisme ne dépend plus qu'un ordinateur personnel soit allumé ou non. Mais quel rapport avec tes premiers prompts, te demandes-tu. Le rapport est profond: c'est l'histoire d'un travail qu'on a lancé et qu'on n'a pas vérifié.

Transpose ça à ta conversation avec une IA. Le contre-exemple typique de l'itération, c'est le "je lance et je pars". Tu écris une demande, la réponse arrive, tu la copies sans la relire et tu passes à autre chose, en supposant que "c'est bon". Comme la tâche sur le mac éteint, tu as fait confiance à un automatisme sans vérifier qu'il avait réellement produit ce qu'il fallait. Et le jour où tu découvres l'erreur, un fait inventé, un ton déplacé, une information périmée, il est souvent trop tard, le message est déjà parti.

L'erreur, dans les deux cas, est la même: absence de vérification, confiance aveugle dans un résultat qu'on n'a pas regardé. Itérer, c'est exactement l'inverse de cette confiance aveugle. C'est rester présent, lire ce qui a été produit, s'assurer que ça correspond, corriger si besoin. La leçon du mac éteint appliquée à toi: ne suppose jamais que le travail a été bien fait, regarde-le. Un résultat non vérifié est un résultat non fiable, qu'il vienne d'un automatisme programmé ou d'une réponse d'IA.

La correction est simple à adopter dès aujourd'hui. Fais de la vérification une étape obligatoire, jamais sautée. Après chaque réponse importante, prends le temps de la lire pour de vrai, de traquer l'invention et la maladresse, et n'utilise que ce que tu as validé de tes yeux. La fiabilité ne vient pas de la machine, elle vient de ta présence attentive à la boucle. C'est ça, itérer sérieusement: rester dans la pièce pendant que le travail se fait, au lieu de partir en supposant que tout ira bien.

• Le mythe du premier coup. Symptôme: tu abandonnes parce que la première réponse n'est pas parfaite. Cause: tu crois qu'un bon prompt doit réussir immédiatement. Réflexe: considère la première réponse comme un brouillon et engage la conversation pour l'affiner.
• Le "fais mieux" vide. Symptôme: tu retapes "recommence" et rien ne s'améliore. Cause: tu n'as pas nommé ce qui clochait. Réflexe: lis vraiment la réponse et dis précisément quoi changer.
• La correction en avalanche. Symptôme: en corrigeant tout d'un coup, la machine s'emmêle et casse ce qui marchait. Cause: trop de reproches dans un seul message. Réflexe: corrige un point à la fois et dis ce que tu veux garder.
• L'enlisement. Symptôme: chaque nouvelle version est bancale autrement, ça tourne en rond. Cause: la conversation est partie dans une mauvaise direction. Réflexe: repars proprement d'une demande neuve enrichie de ce que l'échange t'a appris.
• Le lance-et-pars. Symptôme: tu découvres une erreur après avoir déjà utilisé la réponse. Cause: tu as copié sans relire, confiance aveugle. Réflexe: fais de la vérification une étape obligatoire et garde l'envoi comme un acte séparé et conscient.