1Introduction

Ce guide est le compagnon opérationnel du manuel d'utilisation. Là où le manuel explique les concepts, ce guide fournit des outils directement utilisables: une carte de référence des dix réflexes, des techniques de formulation avec exemples concrets, des flux de travail par type de projet, et des gabarits de prompts prêts à l'emploi.

Chaque section est conçue pour être consultée indépendamment, en cours de session, sans avoir à relire le manuel en entier.

2Les dix réflexes — carte de référence rapide

Ces dix réflexes résument les pratiques les plus efficaces. À consulter en début de session ou à garder à portée de main.

2.1Réflexes de démarrage

–Cadrer dès le début: donner le contexte — qui vous êtes, sur quoi vous travaillez — l'objectif, et les contraintes de format, de langue et de longueur. Ces trois éléments dans le premier message définissent le cadre de toute la conversation.

–Être spécifique: “un paragraphe de cinq lignes en style technique pour un public non spécialiste” vaut infiniment mieux que “écris quelque chose sur ce sujet”. La précision de la demande détermine directement la qualité de la réponse.

–Décomposer: pour toute tâche complexe, commencer par le plan. Ne jamais demander un document de dix pages d'un coup: demander la structure, la valider, puis traiter chaque section une par une.

2.2Réflexes d'itération

–Itérer sans attendre la perfection: le premier essai est rarement le bon, et ce n'est pas le but. Chaque tour de correction affine le résultat. Aller du général vers le particulier.

–Corriger précisément: ne pas dire “ce n'est pas bien, refais”. Expliquer pourquoi ce n'est pas satisfaisant et dans quelle direction aller: fond, structure, ton ou longueur.

–Distinguer régénérer et corriger: régénérer sans corriger sa demande produit un résultat de même nature. Si c'est l'instruction qui était imprécise, écrire un nouveau message correctif.

2.3Réflexes de gestion

–Utiliser les projets: pour tout travail récurrent, travailler dans un projet avec les fichiers de référence téléversés. Une conversation hors projet repart de zéro à chaque fois.

–Vérifier les faits critiques: les erreurs portent surtout sur les données précises, les versions logicielles et les événements récents. Pour tout contenu destiné à être publié ou utilisé en production, vérifier auprès des sources primaires — y compris lorsqu'une recherche web a été faite.

–Clôturer les sessions: cinq minutes de clôture structurée — résumé, points ouverts, suggestions — permettent de démarrer la suivante sans réexpliquer le contexte.

–Maintenir les fichiers du projet: après chaque mise à jour majeure, téléverser la nouvelle version et supprimer l'ancienne. Deux versions d'un même fichier produisent des règles contradictoires.

2.4La règle des trois questions

Avant d'envoyer un message, se poser ces trois questions.

–Est-il clair ce que je veux produire?

–Le contexte et le public sont-ils indiqués?

–Les contraintes de format, de longueur et de style sont-elles données?

Si la réponse à l'une d'elles est “non” ou “peut-être”, compléter le message avant de l'envoyer.

3Techniques de formulation avancées

Ces techniques permettent d'obtenir des résultats nettement supérieurs sur des tâches complexes. Elles sont présentées par ordre de complexité croissante, avec des exemples concrets.

3.1Montrer plutôt qu’expliquer

Au lieu de décrire le format attendu en mots, montrer un ou plusieurs exemples de ce que vous voulez. L'alignement sur la structure, le ton et le niveau de détail est immédiat.

–Principe: fournir un à trois exemples d'entrée et de sortie avant la vraie demande.

–Exemple: “Voici le format de sortie que je veux. Pour chaque capteur, extrais le nom, le type, la localisation et la dernière valeur, séparés par des barres verticales. Exemple: Température salon | Température | Salon | 21,3 °C. Maintenant traite ce fichier de données.”

En voyant l'exemple, le format est reproduit exactement, sans qu'il soit nécessaire de le décrire en détail.

Note:Particulièrement efficace pour les tâches répétitives: extractions de données, reformulations stylisées, classifications, résumés selon un format précis.

3.2Forcer le raisonnement explicite

Pour les tâches qui demandent un raisonnement complexe — analyse, diagnostic, comparaison multicritère — demander explicitement de raisonner étape par étape avant de conclure. La qualité de la réponse finale s'améliore nettement.

–Principe: ajouter “raisonne étape par étape” ou “pense à voix haute avant de conclure”.

–Exemple: “Mon serveur de fichiers n'est plus accessible depuis le réseau secondaire depuis ce matin. Voici la configuration et les journaux. Analyse le problème étape par étape: identifie les causes possibles, élimine celles qui sont incompatibles avec les journaux, puis propose le diagnostic le plus probable et la marche à suivre.”

Note:Utile pour les diagnostics techniques, les analyses d'architecture, les évaluations de risque et les choix entre plusieurs options.

3.3Calibrer le rôle

Assigner un rôle précis oriente le niveau d'expertise, le vocabulaire et le style de réponse. Ce n'est pas de la mise en scène: c'est une façon efficace de spécifier le niveau et le registre attendus.

–Principe: commencer par “tu es”, suivi d'un rôle précis avec son contexte.

–Expertise ciblée: “tu es un ingénieur réseau expérimenté” donne des réponses techniques, sans simplification excessive.

–Registre adapté: “tu es un rédacteur technique qui documente pour des utilisateurs avancés mais non développeurs” ajuste le vocabulaire.

–Revue ciblée: “tu es un architecte domotique expérimenté, revois cette configuration et identifie les problèmes” oriente vers la détection plutôt que l'explication.

Note:Éviter les rôles trop génériques du type “tu es un expert”. Être précis sur le domaine, le niveau et le public cible.

3.4Dire ce qu'on ne veut pas

Spécifier ce que vous ne voulez pas est aussi important que spécifier ce que vous voulez. Les contraintes négatives évitent les réponses génériques et les excès stylistiques fréquents.

–“Ne commence pas par une introduction générale, va directement au point.”

–“N'utilise pas de listes à puces, rédige en prose structurée.”

–“Ne reformule pas ma question, réponds directement.”

–“N'ajoute pas de mise en garde, je connais les limites.”

–“Évite les formules d'enthousiasme en ouverture de réponse.”

3.5Le prompt en deux temps

Pour les documents longs ou complexes, un prompt en deux temps produit des résultats bien supérieurs à une demande unique.

–Premier temps: demander la structure. Valider ou ajuster le plan avant toute rédaction.

–Second temps: donner le feu vert section par section — “traite maintenant la section 2.1 en détail”.

💡Cette méthode s'applique aussi aux scripts de génération. Demander d'abord la liste des fonctions de la feuille de style à utiliser, valider, puis demander le script complet.

3.6Ancrer sur un document de référence

Quand vous voulez un alignement sur un style, un format ou un contenu existant, joindre le document de référence et demander son analyse avant toute production.

Voici le document existant [JOINT]. Analyse son style, sa
structure et son niveau de détail.
 
Produis maintenant un document équivalent sur [NOUVEAU SUJET], en
respectant strictement le même registre et la même organisation.

4Flux de travail par type de projet

Ces flux sont des séquences éprouvées pour les types de projets les plus fréquents. Chacun est conçu pour être suivi session par session, avec des livrables clairs à chaque étape.

4.1Documentation technique

Adapté aux guides d'installation, manuels de configuration, documentation de systèmes, procédures.

Étape Action Livrable Session
1 — Cadrage Définir périmètre, public cible, niveau de détail Note de cadrage validée 1
2 — Inventaire Lister toutes les sections et sous-sections Plan détaillé validé 1
3 — Contenu Rédiger section par section en itération Sections validées 2 à N
4 — Script Générer le script de production via le Kit Script prêt N
5 — Génération Exécuter le script et passer les contrôles Document horodaté et validé N
6 — Révision Relecture, corrections, régénération si besoin Document finalisé N+1
Note:Pour les documents de dix sections ou plus, prévoir une session par groupe de trois sections. Ne pas essayer de tout produire en une seule fois: la fenêtre de contexte se remplit et les premières décisions ne subsistent qu'en résumé.

4.2Analyse et diagnostic

Adapté à l'analyse de journaux, au diagnostic de configuration, à la revue d'architecture, à l'audit et à la comparaison de solutions.

–Joindre tous les fichiers pertinents dès le début.

–Demander une analyse raisonnée étape par étape.

–Valider le diagnostic avant de demander les recommandations.

–Demander les actions correctives par ordre de priorité.

–Demander un résumé de synthèse en fin de session, pour archivage.

💡Pour les analyses complexes, décomposer: d'abord l'inventaire des problèmes, puis la priorisation, puis les solutions. Ne pas tout demander en une fois.

4.3Apprentissage d'un sujet technique

Adapté à la découverte d'une technologie, d'un protocole, d'une interface de programmation ou d'un outil.

–Vue d'ensemble: “donne-moi huit points clés sur ce sujet, pour quelqu'un qui connaît déjà tel domaine”.

–Approfondissement: identifier les deux ou trois points les moins clairs et demander des explications ciblées.

–Ancrage: demander un exemple concret dans votre contexte réel.

–Application: travailler sur un cas pratique réel avec le nouveau savoir.

–Consolidation: demander un résumé structuré à conserver comme référence.

Note:Demandez qu'on vous pose des questions en retour. Ce mode dialogique accélère l'apprentissage et révèle les lacunes que vous n'auriez pas identifiées seul.

4.4Génération de scripts et d'automatisations

Adapté aux scripts de génération de documents, aux automatisations domotiques et aux traitements de données.

–Spécifier précisément les entrées et les sorties avant d'écrire une ligne.

–Demander d'abord la structure du script, la valider avant le code.

–Générer le code section par section pour les scripts longs.

–Tester immédiatement chaque section avant de passer à la suivante.

–Demander une version commentée pour faciliter la maintenance future.

💡Pour les scripts du Kit, joindre la feuille de style active dans la conversation. Les appels seront ajustés aux fonctions réellement disponibles plutôt qu'à celles supposées.

5Gabarits de prompts

Ces gabarits sont des modèles éprouvés pour les situations les plus fréquentes. Copier, adapter les éléments entre crochets, envoyer.

5.1Ouverture de session

À utiliser au début de toute session de travail dans un projet du Kit.

Bonjour. Nouvelle session sur le projet [NOM DU PROJET].
 
Objectif de cette session : [OBJECTIF PRÉCIS — par exemple rédiger
les sections 3 et 4 du guide réseau].
 
Confirme d'abord que tu as bien lu les fichiers du projet, en
particulier [FICHIERS CLÉS — par exemple le prompt projet et la
feuille de style active]. Indique la version de la feuille de style
que tu as lue.

5.2Clôture de session

À utiliser systématiquement en fin de session. Peut être envoyé tel quel.

Avant de clore cette session :
 
1. Résume les fichiers produits avec leurs noms exacts et
   leurs horodatages.
2. Liste les décisions importantes prises pendant la session.
3. Indique les points ouverts — ce qui reste à faire ou à
   vérifier.
4. Propose deux ou trois suggestions pour la prochaine session
   que tu juges utiles mais que nous n'avons pas abordées.
5. Indique quels fichiers je dois téléverser dans le projet
   avant la prochaine session.

5.3Génération de document

À utiliser quand le contenu est validé et qu'on est prêt à produire le document.

Le contenu des sections [LISTE] est validé. Génère maintenant le
script complet pour produire le document.
 
Feuille de style : [FICHIER + VERSION]
Nom de sortie : [PRÉFIXE] - [CATÉGORIE] - [SUJET], horodatage
                     obtenu par la fonction du Kit, jamais saisi
Auteur : [NOM DE L'AUTEUR]
Structure : [niveau 1 pour les sections principales,
                     niveau 2 pour les sous-sections, et ainsi de
                     suite — chaque élément au niveau de son titre
                     parent]
 
Appelle les setters requis par le registre du projet, puis passe
la chaîne de contrôle complète avant de me livrer quoi que ce soit.

5.4Correction ciblée

À utiliser quand une section produite ne correspond pas aux attentes.

La section [NOM] ne convient pas, pour les raisons suivantes :
 
− [PROBLÈME 1 — par exemple trop technique pour le public cible]
− [PROBLÈME 2 — par exemple les points 2 et 3 se chevauchent]
− [PROBLÈME 3 — par exemple le ton est trop formel]
 
Réécris cette section en : [DIRECTION — par exemple langage
accessible, points 2 et 3 fusionnés, ton direct].
 
Conserve : [CE QU'IL FAUT GARDER — par exemple les exemples
concrets et la structure en quatre points].

5.5Analyse de fichier technique

À utiliser pour analyser des journaux, des configurations ou des exports de données.

Voici [TYPE DE FICHIER — par exemple un export de données, des
journaux applicatifs, un fichier de configuration]. [FICHIER JOINT]
 
Analyse ce fichier et produis :
 
1. Un inventaire structuré des [ÉLÉMENTS — par exemple appareils,
   automatisations, erreurs].
2. Les anomalies ou points d'attention que tu identifies.
3. [OPTIONNEL — par exemple des recommandations, ou une
   comparaison avec la configuration précédente].
 
Raisonne étape par étape avant de conclure sur les anomalies.

5.6Reprise de session

À utiliser quand on reprend un projet après une interruption, ou dans une nouvelle conversation.

Bonjour. Je reprends le projet [NOM DU PROJET] après [DURÉE ou
CONTEXTE].
 
Lis les fichiers du projet, en particulier [FICHIERS CLÉS].
Résume en cinq points ce que tu comprends de l'état actuel.
 
Nous allons travailler sur : [OBJECTIF DE CETTE SESSION].
Note:Ces gabarits sont des points de départ. Adaptez-les à votre contexte: la précision de votre formulation est toujours plus efficace qu'un gabarit générique suivi mot pour mot.