Prompt_Engineering de NirDiamant : 22 notebooks pour apprendre les techniques de prompt

Un corpus de techniques, pas une bibliothèque

Le dépôt se présente comme une collection de tutoriels et d'implémentations autour du prompt engineering. La formulation du README est explicite : il sert à apprendre, construire et partager des techniques, des concepts de base aux stratégies avancées. Le sous-titre annonce 22 tutoriels pratiques, du template de prompt simple au chain-of-thought, à la self-consistency et au tree-of-thought. Le public visé est donc celui qui écrit des prompts et veut comprendre pourquoi une formulation fonctionne mieux qu'une autre, pas celui qui cherche une dépendance à ajouter dans un requirements.txt. Le langage principal déclaré est Jupyter Notebook, ce qui est cohérent : la valeur du dépôt est dans les cellules exécutables et les explications qui les entourent, pas dans un module importable. Les topics confirment le positionnement : chain-of-thought, few-shot-learning, in-context-learning, langchain, openai. Un lecteur qui arrive en cherchant un équivalent de guidance ou de DSPy se trompe de porte.

Ce que contient réellement un notebook

Le README ne détaille pas l'anatomie d'un tutoriel, mais l'énoncé du projet et le format Jupyter permettent de décrire la mécanique attendue sans l'inventer. Un notebook de ce type enchaîne trois blocs : une cellule markdown qui pose la technique et le cas d'usage, une ou plusieurs cellules Python qui construisent le prompt et appellent un modèle, puis une cellule qui affiche la réponse pour comparaison. Les topics listent à la fois openai, langchain et claude, ce qui suggère que les appels ne passent pas tous par le même client selon le notebook. C'est un point à vérifier avant de cloner : la présence de plusieurs fournisseurs implique plusieurs façons d'authentifier, et donc plusieurs variables d'environnement possibles. Le README ne documente aucune de ces variables. Il ne documente pas non plus de structure de répertoires, de fichier de configuration commun, ni de requirements.txt dont le contenu serait cité. La seule dépendance dont l'installation est décrite est npm install, et elle concerne l'assistant IA de la formation payante intégré à Claude Code, pas les notebooks eux-mêmes.

Mise en route : ce que le README permet d'affirmer

Il faut être précis ici, parce que le README est pauvre sur ce plan. Aucune commande d'installation Python n'y figure, aucun pip install, aucun nom de paquet. La seule commande citée est npm install, dans le paragraphe qui décrit l'ajout de l'assistant du module gratuit à Claude Code. Le README renvoie aussi vers une page de cours hébergée sur diamant-ai.com, avec un module complet proposé gratuitement, présenté comme une vidéo de 7 minutes accompagnée d'un tutoriel pratique. Ce qui est confirmé : le dépôt est sur la branche main, il n'est pas archivé, et le dernier push date du 4 septembre 2026. Ce qui ne l'est pas : la version de Python requise, les paquets à installer, les clés d'API attendues et leur nom exact. Un lecteur qui veut exécuter un notebook doit donc ouvrir la première cellule de code et lire les imports pour reconstituer l'environnement. C'est faisable, mais c'est un travail que la documentation aurait pu éviter.

Le README comme page de vente

La proportion est frappante. Sur l'extrait fourni, la majorité du contenu encadre une formation payante : bannière de cours, bouton de module gratuit, appel à souscrire à une newsletter, trois vignettes YouTube, deux sponsors, un lien Discord, des liens LinkedIn et Twitter. Le mot prompt engineering apparaît dans le titre et dans l'introduction, puis l'essentiel de la page parle d'autre chose. Ce n'est pas une faute en soi : un mainteneur qui produit des tutoriels gratuits a le droit d'en tirer une activité commerciale, et le dépôt reste accessible. Mais cela détermine la façon de lire le projet. Le README ne sert pas de documentation technique, il sert de tunnel vers un produit. Concrètement, un ingénieur qui cherche à savoir si la technique de self-consistency est implémentée avec un vote majoritaire ou un score de confiance n'obtiendra pas la réponse depuis la page d'accueil. Il devra ouvrir le notebook concerné. Les éléments de preuve sociale présents dans la page, nombre d'abonnés à la newsletter, abonnés YouTube, ne renseignent en rien sur la qualité du code des notebooks.

La licence : NOASSERTION, et ce que cela implique

Le champ licence renvoie NOASSERTION. Concrètement, cela signifie que l'outil d'analyse n'a pas su rattacher le dépôt à une licence SPDX connue, soit parce qu'il n'y a pas de fichier LICENSE, soit parce que le fichier existe mais avec un texte non standard ou modifié. Le README ne mentionne aucune licence. La conséquence pratique est directe : tant que le fichier n'a pas été lu, on ne peut pas savoir si la réutilisation du code dans un produit interne ou dans un dépôt public est permise, si une attribution est exigée, ou si une clause non commerciale s'applique. Pour un usage personnel d'apprentissage, la question est théorique. Pour une entreprise qui voudrait copier une cellule de construction de prompt dans son propre code, elle ne l'est pas. Je ne donne pas de conseil juridique ici, et je ne peux pas trancher à la place du lecteur : le seul geste utile est d'ouvrir le fichier LICENSE à la racine et de le lire avant toute réutilisation. Si ce fichier est absent, l'absence de licence n'équivaut pas à une autorisation.

Ce que le dépôt ne fera pas pour vous

Trois limites ressortent du matériel fourni. D'abord, l'absence de release : aucune version publiée n'a été trouvée, ce qui veut dire qu'il n'existe pas de point de référence stable auquel se rattacher. Un notebook peut changer entre deux lectures, et rien ne permet de citer une révision fonctionnelle. Ensuite, l'absence de tests et de configuration partagée. Le format Jupyter se prête mal à l'intégration continue, et rien dans le README n'indique qu'il en existe. Un notebook qui casse parce qu'un client d'API a changé sa signature ne sera pas signalé par une alerte. Enfin, le coût d'exécution. Chaque tutoriel appelle un modèle, souvent plusieurs fois pour comparer des variantes. Les techniques avancées citées, self-consistency et tree-of-thought, reposent par construction sur plusieurs générations par question. Un lecteur qui exécute les 22 notebooks d'affilée paie l'ensemble des appels. Le README n'aborde ni ce point ni un mode hors ligne. C'est le cas où le dépôt est le mauvais outil : une équipe qui cherche une abstraction testée pour orchestrer des prompts en production n'a rien à faire ici.

Face à un cadre d'évaluation comme promptfoo

L'alternative la plus proche n'est pas un autre recueil de tutoriels, c'est un outil d'évaluation de prompts, promptfoo étant l'exemple le plus courant. La différence de nature est nette. Ici, on lit une technique, on l'exécute une fois dans une cellule, et on juge la sortie à l'œil. Avec promptfoo, on décrit les prompts et les cas de test dans un fichier de configuration YAML, on lance la comparaison en ligne de commande, et on obtient un tableau de résultats reproductible entre modèles et entre variantes de prompt. Le premier enseigne pourquoi une formulation marche. Le second mesure de combien elle marche, sur un jeu de cas fixé, et permet de détecter une régression après un changement de modèle. Un lecteur qui a compris le chain-of-thought dans un notebook et qui veut savoir si sa propre version du prompt tient sur 200 exemples réels a besoin du second outil, pas d'un vingt-troisième tutoriel. Le choix entre les deux dépend d'une seule question : est-ce que je cherche à comprendre, ou est-ce que je cherche à décider entre deux versions ?

Coût de maintenance et suite à donner

Le dépôt n'est pas archivé et le dernier push est récent, ce qui indique une maintenance active au moment de la rédaction. Mais l'absence de release signifie que cette maintenance se traduit par des modifications directes sur main, sans journal de versions. Pour un utilisateur, cela implique de figer soi-même une copie, par exemple en clonant et en notant le commit utilisé, si l'on veut pouvoir reproduire un résultat plus tard. Le coût réel n'est pas dans l'installation, il est dans la dérive : les SDK de fournisseurs de modèles changent leurs interfaces, et chaque notebook qui les appelle devra être corrigé indépendamment, faute de couche d'abstraction commune visible dans le matériel fourni. Le README, lui, oriente vers un cours payant de 20 modules et vers une newsletter. Rien n'indique un engagement de maintenance sur les notebooks eux-mêmes. La première vérification à faire reste donc l'ouverture du fichier LICENSE, suivie de l'inspection des imports de la première cellule du notebook qui vous intéresse. Ces deux lectures prennent quelques minutes et déterminent si le reste vaut votre temps.

Conclusion éditoriale

Ce dépôt convient à un développeur qui veut du code exécutable pour comprendre chain-of-thought, self-consistency ou tree-of-thought, et à un formateur qui cherche un support de cours déjà découpé. Il ne convient pas à une équipe qui veut une bibliothèque installable en production : il n'y a pas de release, pas de version publiée, et la licence reste à clarifier. Avant de réutiliser un notebook, vérifiez deux choses : le fichier LICENSE à la racine, et le nom exact des clés d'API attendues dans la première cellule de code du notebook que vous ouvrez.

Sources officielles

1. Issues
2. NirDiamant/Prompt_Engineering on GitHub
3. Project website
4. README