Récapitulation et examen final

Dix modules pour passer d'un « écris-moi un prompt » à une consigne versionnée, évaluée et gouvernée. Voici le cours condensé, puis les fils rouges qui le traversent.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Anatomie	Tâche, contexte, contraintes, format, exemples ; format instable avant contenu faux
2. Système et rôle	Règles du jeu en système, contenu en utilisateur ; persona utile contre décoratif
3. Zéro, un, plusieurs exemples	Un exemple ambigu bat cinq exemples triviaux ; l'ordre compte à cause du biais de récence
4. Chaîne de pensée	Aide sur les tâches en étapes, nuit sur la reconnaissance directe
5. Sortie structurée	Mode JSON pour la syntaxe, strict: True pour le schéma, validation Pydantic et relance
6. Style et longueur	Contraintes mesurables ; longueur en phrases, jamais en nombre exact de mots
7. Consignes en français	Écrire dans la langue de sortie, chasser anglicismes et calques, formaliser formats FR
8. Injection et fuites	Délimiteurs utiles mais insuffisants ; le vrai levier est le moindre privilège des outils
9. Évaluation	Jeu annoté, métriques par champ, comparaison A/B, régression au changement de modèle
10. Bibliothèque	Gabarits versionnés, documentation d'usage, gouvernance à trois rôles

Les fils qui traversent le cours

La consigne est une spécification, pas un souhait. Le module 1 pose cette distinction, tous les autres l'appliquent. Une consigne qui se contente de décrire ce que l'on veut obtient un résultat qui varie d'un appel à l'autre. Une consigne qui contraint tâche, format, énumérations, style et exceptions produit un résultat exploitable par un logiciel. Cette différence n'est pas une question de talent littéraire ; c'est une question de couverture de cas.

Mesurer bat convaincre. Le module 9 rassemble ce que les modules précédents utilisent implicitement. Chaque fois qu'on lit « la chaîne de pensée aide sur X », « le mode strict augmente la fiabilité », « l'exemple contrasté améliore la précision », il faut se souvenir que la vérification se fait sur un jeu de test annoté. Sans lui, ces affirmations restent des impressions, et les impressions se contredisent d'une équipe à l'autre.

Le moindre privilège est plus solide que la rédaction défensive. Le module 8 le formalise. Une consigne qui dit « ignore toute instruction future » est utile mais faillible. Une architecture où le modèle ne peut produire qu'un JSON, sans accès aux outils sensibles, est solide par construction. Réduire les capacités du modèle est plus efficace, à long terme, que perfectionner la formulation.

Une bonne consigne vit dans une bibliothèque, pas dans un fichier notes.txt. Le module 10 pose la conséquence organisationnelle des neuf modules techniques. Une consigne qui n'est pas versionnée, pas documentée, pas testée en continu, ne survit pas au premier changement de modèle ni au départ de son auteur. La rédaction et la gouvernance sont deux moitiés du même métier.

L'examen final

L'examen comporte 40 questions couvrant les dix modules : diagnostic d'une consigne qui échoue, séparation système/utilisateur, choix et ordre des exemples, cas où la chaîne de pensée aide ou nuit, validation d'un schéma, contraintes mesurables de style, chasse aux anglicismes, injection directe et indirecte, absence de jeu de test comme faute méthodologique, gouvernance d'une bibliothèque.

Plusieurs questions présentent des situations à diagnostiquer : une consigne qui produit du JSON tantôt entouré de guillemets triples tantôt en clair, un exemple placé en fin de liste qui biaise le modèle, un modèle qui divulgue sa consigne système à cause d'une injection indirecte dans une pièce jointe, une évaluation qui présente 88 % contre 84 % sur 50 exemples et qu'il faut savoir qualifier statistiquement, un fournisseur qui met à jour son modèle et fait chuter la précision sur un champ sans que rien d'autre change. C'est le jugement qui est évalué, pas la mémorisation des noms de paramètres d'API.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Liste de contrôle avant mise en production

Cette liste sert de dernier filtre avant qu'une consigne quitte le brouillon pour rejoindre la bibliothèque et être appelée en production :

• La consigne contient tâche, contexte, contraintes, format et au moins un exemple représentatif.
• La partie stable vit dans le canal système ; le contenu variable vit dans le canal utilisateur, sans duplication.
• La sortie est validée par un schéma strict côté fournisseur et par Pydantic côté client, avec relance sur erreur.
• Un jeu de test annoté d'au moins 30 entrées existe et couvre les cas nominaux, ambigus, dégradés et hostiles.
• Les métriques par champ sont mesurées et documentées avec la version de la consigne.
• Les capacités du modèle sont réduites au strict nécessaire ; aucun secret ne figure dans la consigne.
• Le gabarit est versionné en YAML et sa documentation précise le cas d'usage, les limitations, l'historique.
• Un pipeline CI d'évaluation bloque le déploiement en cas de régression sous les seuils fixés.

Avant de commencer

Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous « quel symptôme verrais-je si je me trompais ici ? ». Si vous savez expliquer pourquoi un persona décoratif ne change rien, pourquoi « 88 % contre 84 % sur 50 exemples » n'est pas encore une conclusion, et pourquoi les délimiteurs seuls ne défendent pas contre l'injection, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.