Prompt Engineering : Guide Complet pour Développeurs 2026

Temps de lecture estimé : 30 minutes

Le livre blanc : « Prompt
Engineering par Lee Boonstra« 

Ecoutez le podcast sur le Prompt Engineering

Prompt Engineering : Le Guide Complet pour Développeurs (2026)

Le prompt engineering transforme radicalement la manière dont nous développons avec l’IA. Entre nous, quand j’ai intégré mes premiers LLMs dans GymLog (mon app fitness), je croyais qu’il suffisait de « demander gentiment » à l’IA. Résultat ? Des réponses bancales, du code buggé, et une prod qui a failli partir en vrille. Ce qu’il faut comprendre, c’est que l’ingénierie de prompt, c’est du développement, pas de la conversation.

Après 25 ans à coder (du PHP spaghetti des années 2000 aux stacks Next.js modernes), j’ai décortiqué le whitepaper de Lee Boonstra, ingénieure au bureau du CTO chez Google. Son approche pragmatique m’a permis de passer du stade « utilisateur qui chatte » à celui d’ingénieur qui architecture ses prompts comme des appels API. Et franchement, ça change tout.

Dans ce guide, on va voir ensemble comment maîtriser le prompt engineering : des fondamentaux (température, few-shot) aux techniques avancées (Chain-of-Thought, ReAct), en passant par le workflow « Super-Prompt » de Gemini que j’utilise quotidiennement dans VS Code chez WebNyxt. Concrètement, vous allez apprendre à programmer l’IA pour qu’elle devienne une extension fiable de votre cerveau.

Qu’est-ce que le Prompt Engineering et Pourquoi est-ce Essentiel ?

Pour être totalement transparent, il faut arrêter de mystifier l’outil. Lee Boonstra l’explique parfaitement avec une analogie tirée de Matilda de Roald Dahl : imaginez une enfant de 4 ans qui a lu tous les livres d’une bibliothèque publique. Elle a une connaissance encyclopédique, elle est devenue un génie par ingestion massive de données (des pétaoctets, pour être précis).

Mais attention, contrairement à Matilda, l’IA ne « sait » rien. C’est un moteur de prédiction statistique. Quand vous posez une question à un LLM (Large Language Model), il ne cherche pas la vérité. Il calcule le prochain mot (token) le plus probable en se basant sur des milliards de textes ingurgités pendant son entraînement.

Si je demande « Qui est le président des USA ? », le modèle répond « Joe Biden » (ou Donald Trump selon sa date de coupe) non pas parce qu’il comprend le concept de politique, mais parce que dans son dataset, ces mots sont statistiquement liés. Plus précisément, c’est comme un autocomplétion surpuissante qui prédit le mot suivant, puis le suivant, jusqu’à former une phrase cohérente.

À retenir : Un LLM ne comprend rien, il prédit. C’est une nuance critique pour nous, les développeurs, car si c’est des maths et des stats, ça veut dire que c’est configurable.

Le prompt engineering est donc la discipline qui consiste à écrire des instructions optimisées pour obtenir des réponses fiables, précises et structurées. D’après les recherches de Google, une ingénierie de prompt efficace améliore la qualité des sorties de 40 à 60% par rapport à des prompts basiques. Autant dire que c’est un investissement qui paie.

Pourquoi est-ce essentiel en 2026 ? Parce que les LLMs sont partout : génération de code, automatisation de workflows (mes fameux n8n), analyse de données, support client… Si vous ne maîtrisez pas l’art du prompting, vous allez perdre un temps fou à corriger des outputs médiocres. Et croyez-moi, j’en ai perdu du temps avant de comprendre ça.

Les Fondamentaux du Prompt Engineering

Comprendre le Fonctionnement des LLMs

Avant de configurer quoi que ce soit, comprenons ce qui se passe sous le capot. Un large language model, c’est une architecture de réseaux de neurones (souvent des Transformers) entraînée sur des corpus textuels gigantesques. Le modèle apprend à prédire le prochain token en fonction du context window (la fenêtre de contexte), c’est-à-dire tout ce qu’il a « vu » depuis le début de la conversation.

Concrètement, quand vous soumettez un prompt, le modèle décompose votre texte en tokens (morceaux de mots), calcule des probabilités pour chaque token suivant possible, et en sélectionne un selon des paramètres configurables. Ce processus se répète jusqu’à ce que le modèle décide de s’arrêter (token de fin de séquence) ou atteigne une limite.

La taille du context window est cruciale. Les premiers GPT étaient limités à 4 000 tokens (~3 000 mots). Aujourd’hui, Gemini 1.5 Pro de Google offre une fenêtre de 1 à 2 millions de tokens. Pour un développeur comme moi, ça change tout : je peux balancer l’intégralité d’une documentation technique, plusieurs fichiers de code, ou même une vidéo entière (multimodalité) en entrée. L’IA peut enfin « voir » tout le projet au lieu de travailler aveuglément sur un fichier isolé.

Paramètres Clés : Temperature, Top-K et Top-P

Vous ne lanceriez pas un serveur Node.js sans configurer vos variables d’environnement, non ? Alors pourquoi lancer un prompt sans toucher aux paramètres du modèle ?

La température est le premier réglage à maîtriser. Elle contrôle le degré de hasard dans la sélection des tokens. Une température de 0 rend le modèle déterministe : il choisit presque toujours le token le plus probable. C’est impératif quand on génère du code, du JSON ou qu’on fait des maths. On veut que 2 + 2 fasse toujours 4, pas « environ 4 » ou « peut-être 3,8 ».

À l’inverse, une température élevée (0.7 à 1.0+) introduit de l’aléatoire. Le modèle explore des tokens moins probables, ce qui génère de la créativité. Utile pour du brainstorming ou de la rédaction littéraire, mais dangereux pour la production. Entre nous, si votre bot hallucine (invente des faits), baissez la température avant de réécrire votre prompt.

Paramètre	Fonction	Valeur recommandée	Cas d’usage
Temperature	Contrôle l’aléatoire et la créativité	0 – 0.2 (factuel) 0.7 – 1.0 (créatif)	Code, JSON, maths (bas) Rédaction, idéation (haut)
Top-K	Limite aux K tokens les plus probables	20 – 40	Éviter les délires improbables
Top-P	Sélectionne tokens jusqu’à probabilité cumulée P	0.9 – 0.95	Équilibre cohérence/diversité

Le Top-K limite la sélection aux K tokens les plus probables (ex : les 40 meilleurs mots suivants). Ça évite que l’IA parte dans des délires totalement improbables. Le Top-P (nucleus sampling) fonctionne différemment : il sélectionne les tokens dont la probabilité cumulée atteint un seuil P (ex : 0.95). C’est un peu technique, mais en pratique, ça permet un meilleur équilibre entre cohérence et diversité.

Dans mes workflows d’automatisation n8n pour WebNyxt, je règle souvent : Temperature: 0.2, Top-P: 0.95, Top-K: 30. Résultat ? Des réponses factuelles, précises et reproductibles. À vous d’adapter selon votre use case.

Anatomie d’un Prompt Efficace

Un prompt efficace, c’est comme une fonction bien documentée : il doit être clair, spécifique et structuré. Google recommande quatre composantes essentielles :

• Rôle — Définir qui est l’IA (ex: « Tu es un expert Python Senior spécialisé en FastAPI »)
• Tâche — Expliquer précisément ce qu’elle doit faire
• Contexte — Fournir les informations nécessaires (données, contraintes, style)
• Format attendu — Spécifier la structure de sortie (JSON, markdown, code commenté)

Donner un rôle à l’IA, ce n’est pas juste pour le fun. Ça active des zones latentes spécifiques du modèle. Au lieu de demander « Écris un script Python », j’écris : « Tu es un Expert Backend Python Senior spécialisé dans FastAPI et les architectures propres. Ton code doit être typé (type hints) et documenté (docstrings). Génère un endpoint REST pour créer un utilisateur avec validation Pydantic. »

Ce simple ajout de rôle définit le ton, le niveau de vocabulaire et la qualité attendue. D’ailleurs, c’est la base du workflow « Super-Prompt » qu’on verra plus loin.

Techniques Fondamentales de Prompting

Zero-Shot Prompting

Le zero-shot prompting, c’est l’approche basique : vous donnez une instruction directe sans fournir d’exemples. Le modèle s’appuie uniquement sur ses connaissances préalables (ce qu’il a vu pendant l’entraînement).

Exemple Zero-Shot :
« Classe cet avis client : ‘Le produit est arrivé cassé, service client inexistant.' »
Réponse attendue : « Négatif »

Ça marche pour des tâches simples, mais dès que la logique se complique ou que vous voulez un format spécifique (JSON, tableau), c’est la porte ouverte aux erreurs. Plus précisément, le modèle va interpréter à sa façon, et vous allez devoir parser manuellement des outputs inconsistants. Bref, une perte de temps.

One-Shot et Few-Shot Prompting

C’est là que ça devient intéressant. Le few-shot prompting consiste à donner au modèle quelques exemples de couples « Input → Output souhaité » avant de poser votre vraie question. C’est le principe du « Show, Don’t Tell » appliqué à l’IA.

Les recherches montrent que le few-shot améliore l’accuracy jusqu’à +28,2% par rapport au zero-shot. Concrètement, au lieu d’expliquer ce que vous voulez, vous le montrez. Le modèle détecte le pattern et le reproduit. Et croyez-moi, pour forcer une structure JSON stricte dans mes automatisations, c’est radical.

Voici l’exemple emblématique de Lee Boonstra, que j’utilise quotidiennement pour parser des emails de commande :

Prompt Few-Shot (Exemple Pizza JSON) :

Convertis les commandes de pizza en JSON valide.

Exemple :
Input : « Je veux une petite pizza fromage et tomates. »
Output : { « size »: « small », « ingredients »: [« cheese », « tomato »] }

Exemple :
Input : « Une grande avec basilic et mozza. »
Output : { « size »: « large », « ingredients »: [« basil », « mozzarella »] }

Input : « Je voudrais une grande pizza, moitié fromage, moitié jambon ananas. »
Output : { « size »: « large », « ingredients »: [« cheese », « ham », « pineapple »] }

En faisant ça, vous forcez le modèle à reproduire la structure JSON. C’est bien plus fiable que de simplement dire « Fais-moi un JSON ». Lee Boonstra a utilisé une logique similaire pour Wendy’s : convertir les commandes vocales complexes du drive (« Je veux le burger de Dave mais sans cornichons, avec des frites moyennes et un Coca zéro ») en commandes structurées pour la cuisine. Résultat ? Moins d’erreurs, meilleure expérience client.

Conseil Nicolas : Pour vos APIs qui consomment des LLMs, utilisez systématiquement le few-shot avec 2-3 exemples JSON. Vous allez diviser par 10 les erreurs de parsing. Dans la pratique, ça évite d’écrire des regex de validation complexes derrière.

Rôles et Contextes : Cadrer l’Expert

On l’a évoqué, mais insistons : assigner un rôle à l’IA, c’est activer des patterns spécifiques dans le modèle. Si je demande « Écris un script Python pour scraper un site web », le modèle va me sortir du code basique, probablement avec requests et BeautifulSoup.

Mais si j’écris : « Tu es un Expert Python Senior spécialisé en web scraping éthique et légal. Ton code respecte les robots.txt, gère les timeouts et les erreurs HTTP, et utilise des User-Agents valides. Écris un scraper asynchrone avec aiohttp et BeautifulSoup pour extraire les titres d’articles depuis https://example.com/blog. »

Là, je vais obtenir un code typé, avec gestion d’erreurs, respect des bonnes pratiques, et probablement des commentaires explicatifs. La différence est énorme. Ce qu’il faut comprendre, c’est que le rôle définit le niveau d’expertise, le ton, et même les bibliothèques privilégiées par le modèle.

D’ailleurs, c’est exactement ce qu’on va exploiter dans la section « Super-Prompts » avec les fichiers GEMINI.md.

Techniques Avancées pour Cas Complexes

Vous avez configuré votre température, vous avez donné des exemples (few-shot)… mais parfois, l’IA se plante encore sur des trucs qui semblent basiques, comme des maths ou de la logique. C’est normal. Rappelez-vous : c’est un moteur de prédiction de mots, pas une calculatrice.

Chain-of-Thought (CoT) Prompting

C’est ma technique préférée pour le debugging logique. Le concept est simple : les LLMs sont mauvais en calcul mental immédiat, mais très bons si on les force à décomposer le problème étape par étape. On appelle ça le Chain-of-Thought prompting (chaîne de pensée).

Prenons cet exemple classique d’échec en zero-shot :

Prompt : « Quand j’avais 3 ans, mon frère avait la moitié de mon âge. J’ai maintenant 40 ans. Quel âge a mon frère ? »
Réponse (souvent fausse) : « 20 ans. » (Le modèle fait bêtement 40 / 2)

Pour corriger ça, on utilise le Chain-of-Thought. Il suffit d’ajouter une phrase magique à la fin du prompt : « Let’s think step by step » (Réfléchissons étape par étape) ou « Raisonne étape par étape » en français.

Prompt CoT : « Quand j’avais 3 ans, mon frère avait la moitié de mon âge (donc 1,5 an). J’ai maintenant 40 ans. Quel âge a mon frère ? Raisonne étape par étape. »

Réponse :
1. Tu avais 3 ans, ton frère avait 1,5 an.
2. La différence d’âge est de 3 – 1,5 = 1,5 an.
3. Tu as maintenant 40 ans.
4. Ton frère a donc 40 – 1,5 = 38,5 ans.

En tant que développeur, j’utilise ça pour générer des scripts de migration de données : je demande à l’IA de lister d’abord les risques et les étapes avant d’écrire la moindre ligne de SQL. Résultat ? Des migrations plus sûres, avec gestion des rollbacks. Franchement, ça m’a sauvé plusieurs fois.

Self-Consistency : Voter pour Réduire les Hallucinations

Voici une technique avancée pour améliorer la fiabilité : la self-consistency. Le principe ? Générer plusieurs réponses indépendantes (avec une température élevée pour introduire de la variation), puis sélectionner la réponse la plus fréquente par majority vote.

Concrètement, vous lancez le même prompt 5 fois avec temperature: 0.8. Si 4 réponses sur 5 disent « 38,5 ans » et 1 dit « 20 ans », vous retenez « 38,5 ans ». Cette technique réduit significativement les hallucinations, surtout sur des problèmes de raisonnement.

C’est ce qu’on appelle un mécanisme de « vote démocratique » entre plusieurs runs du modèle. En vrai, c’est coûteux en tokens (vous payez 5 fois plus), mais pour des décisions critiques en production, ça vaut le coup. J’utilise ça dans mes workflows d’analyse automatique de contrats pour WebNyxt : extraire des clauses sensibles avec une fiabilité maximale.

Step-Back Prompting

Parfois, le modèle a le nez dans le guidon. Le step-back prompting consiste à lui demander de répondre d’abord à une question générique sur le concept avant de s’attaquer à votre problème spécifique.

Par exemple, si je veux qu’il m’écrive une architecture React complexe, je lui demande d’abord : « Quelles sont les meilleures pratiques d’architecture pour une app React scalable en 2026 ? ». Ensuite, j’injecte cette réponse (son propre savoir) dans le prompt final pour générer mon code.

Ça active les connaissances contextuelles du modèle. Plus précisément, en prenant du recul, l’IA se « rappelle » des principes généraux (SOLID, séparation des concerns, state management) avant de coder. Résultat ? Un code mieux structuré, avec moins de dette technique. Et croyez-moi, sur des projets qui durent 6 mois, ça fait toute la différence.

Tree of Thoughts (ToT)

Le Tree of Thoughts est une extension du Chain-of-Thought. Au lieu de suivre un raisonnement linéaire, le modèle explore plusieurs branches de pensée en parallèle, comme un arbre de décision.

Imaginez que vous devez résoudre un problème d’optimisation avec plusieurs solutions possibles. Avec ToT, le modèle génère 3-4 approches différentes, évalue chacune, puis sélectionne la meilleure ou combine les insights. C’est particulièrement utile pour des problèmes créatifs ou des dilemmes avec trade-offs.

Dans la pratique, c’est plus cher en tokens et en latence, donc je le réserve aux cas vraiment complexes : architecture de microservices, stratégies de scaling, ou choix technologiques impactants. Mais quand vous avez besoin d’explorer plusieurs options avant de décider, c’est redoutable.

ReAct (Reasoning + Acting)

C’est le futur de nos métiers. ReAct (Reason & Act) permet au modèle de ne pas juste parler, mais d’utiliser des outils. Lee Boonstra montre comment connecter Gemini à Google Search ou à un interpréteur Python. Le modèle fonctionne dans une boucle itérative :

1. Thought (Pensée) : « Je dois trouver la météo actuelle à Paris. »
2. Action : Exécuter l’API Météo externe.
3. Observation : Récupérer le JSON de l’API (ex: {"temp": 15, "condition": "nuageux"}).
4. Réponse finale : « Il fait 15°C à Paris et c’est nuageux. »

Concrètement, ça permet de créer des agents autonomes. Pour automatiser des tâches DevOps (comme checker des logs serveurs, analyser des métriques, et redémarrer un pod Kubernetes si besoin), ReAct est une tuerie. On sort du simple « chatbot » pour entrer dans le monde des agents intelligents capables d’agir dans le monde réel.

J’expérimente ça avec n8n et LangChain chez WebNyxt : des workflows où l’IA décide elle-même quelles API appeler en fonction du contexte. Autant dire que ça ouvre des perspectives folles pour l’automatisation.

Technique	Complexité	Cas d’usage	Performance
Zero-Shot	Faible	Tâches simples, classification basique	Baseline (100%)
Few-Shot	Moyenne	Structure forcée (JSON), style spécifique	+28% accuracy
Chain-of-Thought	Moyenne	Raisonnement, maths, logique complexe	+40-60% sur problèmes logiques
Self-Consistency	Élevée	Décisions critiques, réduction hallucinations	+15-25% fiabilité
ReAct	Élevée	Agents autonomes, intégration outils externes	Variable selon qualité des outils

Best Practices et Optimisation de Prompts

Rédiger des Instructions Claires et Spécifiques

On ne va pas se mentir : un prompt vague donne un output vague. La première règle de l’optimisation, c’est la clarté. Google insiste là-dessus dans son whitepaper : « Be specific and clear about what you want. »

Voici les best practices que j’applique systématiquement :

• Soyez ultra-spécifique — Au lieu de « Écris du code », écrivez « Écris une fonction Python async qui récupère les 10 derniers tweets d’un utilisateur via l’API Twitter v2, gère les rate limits et retourne un DataFrame pandas. »
• Privilégiez les instructions positives — Dites « Utilise TypeScript » plutôt que « N’utilise pas JavaScript ». Le modèle comprend mieux ce qu’il DOIT faire que ce qu’il NE DOIT PAS faire.
• Spécifiez le format de sortie — « Réponds en JSON avec les champs : name, age, email » ou « Génère du code avec des commentaires inline et une docstring. »
• Utilisez des variables pour réutiliser — Si vous générez des prompts dans votre code, utilisez des templates avec variables : f"Tu es un {role}. Génère {output_type} pour {use_case}."
• Donnez des contraintes quantifiables — « En 200 mots maximum », « Avec exactement 5 bullet points », « Code en moins de 50 lignes ».
• Structurez avec des sections — Pour des prompts longs, utilisez des sections claires : ## Contexte\n## Tâche\n## Format attendu.
• Évitez l’ambiguïté — « Optimise ce code » est flou. « Refactorise ce code pour réduire la complexité cyclomatique en dessous de 10 et extraire les fonctions de plus de 20 lignes » est clair.

Astuce : J’ai un snippet VS Code pour mes prompts de génération de code. Ça me permet de rester cohérent et de ne jamais oublier de spécifier le typage ou les tests.

Utiliser le Contexte de Manière Stratégique

Le contexte, c’est le carburant du modèle. Plus vous donnez d’informations pertinentes, meilleure sera la réponse. Mais attention : contexte pertinent ≠ contexte exhaustif. Fournir 50 pages de documentation quand 2 paragraphes suffisent, c’est diluer le signal dans le bruit.

Définir un persona ou rôle : On l’a vu, mais insistons. Assigner un rôle cadre immédiatement le ton et l’expertise. « Tu es un DevOps spécialisé en Kubernetes » va générer des configs YAML propres, avec ressources limits/requests et health checks. Sans ce rôle, vous allez avoir des configs minimalistes et dangereuses.

Adapter le ton et la perspective : Si vous générez du contenu pour un blog technique, précisez : « Ton : expert mais accessible, avec exemples concrets. Évite le jargon non expliqué. » Le modèle va automatiquement ajuster son vocabulaire et son niveau de détail.

Exemple concret : quand je génère des emails automatiques pour mes clients WebNyxt, je spécifie toujours : « Ton professionnel mais chaleureux, tutoiement, signature ‘Nicolas D. – WebNyxt' ». Résultat ? Des emails qui sonnent humains, pas comme des templates génériques.

Prompt sans contexte : « Écris une fonction de validation d’email. »
Output : Regex basique sans gestion des cas limites.

Prompt avec contexte : « Tu es un expert sécurité. Écris une fonction Python de validation d’email RFC 5322 compliant, avec gestion des domaines internationalisés (IDN) et protection contre les injections. Utilise la lib email-validator. »
Output : Code robuste, sécurisé et production-ready.

La différence est énorme. Entre nous, le contexte, c’est votre levier de contrôle sur la qualité.

Itérer et Évaluer les Sorties

Lee Boonstra le dit clairement dans son whitepaper : « Everyone can write a prompt, but crafting the effective prompt takes time. » L’ingénierie de prompt, c’est du développement itératif. Vous écrivez un prompt, vous testez, vous mesurez, vous ajustez. Comme n’importe quel code.

Processus d’amélioration continue :

1. Générer plusieurs outputs — Lancez le prompt 3-5 fois pour identifier les variations.
2. Évaluer la qualité — Vérifiez : précision, format, ton, absence d’hallucinations.
3. Identifier les failles — Où le modèle se trompe-t-il ? Quelle partie de l’instruction est ambiguë ?
4. Ajuster le prompt — Ajoutez du contexte, précisez le format, baissez la température.
5. Re-tester — Jusqu’à obtenir une qualité constante sur 10+ runs.

Pour mes projets en production, je fais systématiquement de l’A/B testing de prompts. Je lance deux versions (A et B) sur 100 inputs, je mesure la qualité (précision, temps de réponse, coût en tokens), et je garde la meilleure. Dans la pratique, ça peut améliorer les résultats de 20-30% et réduire les coûts de 15% en optimisant les tokens.

Conseil Nicolas : J’ai un fichier Excel (oui, à l’ancienne) où je note mes meilleurs prompts pour mes clients. Colonnes : Use Case, Prompt, Paramètres (temp, top-p), Performance (accuracy, coût). Ça me permet de capitaliser sur ce qui marche et de ne pas réinventer la roue à chaque projet.

Checklist de validation d’un prompt avant production :

• Le rôle est clairement défini
• La tâche est spécifique et sans ambiguïté
• Le contexte pertinent est fourni (pas de superflu)
• Le format de sortie est explicitement spécifié
• Les contraintes (longueur, style, limites) sont précisées
• Les paramètres (temperature, top-p) sont adaptés au cas d’usage
• Le prompt a été testé sur 10+ inputs variés
• Aucune hallucination détectée sur les tests
• Le coût en tokens est optimisé (pas de contexte inutile)
• La latence est acceptable pour l’expérience utilisateur

Applications Pratiques et Cas d’Usage

Génération de Code et Documentation

C’est le use case numéro 1 pour nous, les développeurs. Lee Boonstra montre que les LLMs peuvent générer du code production-ready si le prompt est bien structuré. Concrètement, j’utilise l’IA pour :

Générer des fonctions complètes : Plutôt que de coder une fonction de A à Z, je décris ce que je veux. Exemple : « Écris une fonction TypeScript async qui fetch des données depuis une API REST, gère les erreurs HTTP (401, 403, 500), implémente un retry logic avec exponential backoff (max 3 tentatives), et retourne un Result type-safe. » En 10 secondes, j’ai un code propre, typé, avec gestion d’erreurs robuste.

Générer des tests unitaires : Je colle une fonction, je demande : « Génère des tests Jest pour cette fonction. Couvre les cas nominaux, les cas limites (null, undefined, string vide) et les erreurs. » Résultat ? Une suite de tests complète que je n’aurais pas eu la patience d’écrire manuellement. Et franchement, ça améliore la qualité du code.

Documentation automatique : J’ai un script qui parcourt mon code, extrait les fonctions sans docstring, et génère automatiquement des commentaires JSDoc ou docstrings Python. Gain de temps énorme. Le prompt : « Analyse cette fonction et génère une docstring complète (description, params, return, exceptions). »

Exemple de prompt pour API :

« Tu es un expert FastAPI. Génère un endpoint POST /users qui :
– Accepte un UserCreate Pydantic model (name: str, email: EmailStr, age: int)
– Valide l’email avec regex
– Sauvegarde en DB (assume session SQLAlchemy disponible)
– Retourne un UserResponse model (id: int, name: str, created_at: datetime)
– Gère les erreurs (email déjà existant → 409, validation échouée → 422)
– Inclut des commentaires et une docstring »

Avec ce niveau de détail, le code généré est quasi production-ready. Je n’ai plus qu’à ajuster 2-3 détails et à intégrer dans mon projet.

Classification et Extraction de Données

Pour les tâches de classification ou d’extraction structurée, le few-shot prompting est redoutable. Voici comment je l’utilise :

Classification de texte : Analyser des avis clients, classer des tickets de support, catégoriser des emails. Avec 3 exemples en few-shot, le modèle comprend les nuances (ex : différencier « bug critique » vs « amélioration souhaitée » vs « question support »).

Extraction structurée (JSON) : Extraire des entités depuis du texte non structuré. Exemple : analyser un email de commande complexe (« Bonjour, je voudrais commander 3 T-shirts bleus taille M et 2 casquettes noires pour livraison le 15 mars à Lyon ») et sortir un JSON :
{"items": [{"product": "T-shirt", "color": "blue", "size": "M", "quantity": 3}, {"product": "casquette", "color": "black", "quantity": 2}], "delivery_date": "2026-03-15", "city": "Lyon"}

Analyse de sentiment : J’automatise l’analyse de retours clients pour WebNyxt. Le prompt : « Analyse cet avis et retourne en JSON : {sentiment: ‘positive’|’negative’|’neutral’, score: 0-10, key_points: [liste des points mentionnés], action_needed: bool}. »

Résultat ? Je peux traiter 1000 avis en quelques minutes et prioriser ceux qui nécessitent une action immédiate. Entre nous, ça m’a fait gagner des heures de travail manuel fastidieux.

Résumés, Traductions et Réécriture

Résumés avec contraintes : « Résume cet article technique en 150 mots, niveau expert, format bullet points, garde les chiffres clés. » Ou : « Résume ce rapport de 50 pages en 3 paragraphes exécutifs (contexte, insights, recommandations). » L’IA excelle là-dessus, surtout avec la fenêtre de contexte de Gemini (1M+ tokens).

Traduction multilingue avec style : Pas juste traduire mot à mot, mais adapter le ton et la culture. « Traduis ce texte marketing en espagnol (Espagne, pas Amérique Latine), ton enthousiaste mais professionnel, adapte les références culturelles. » Le résultat sonne naturel, pas comme du Google Translate.

Réécriture avec ton spécifique : J’ai des contenus techniques que je dois adapter pour différents publics. « Réécris ce paragraphe technique pour un public non-technique, utilise des analogies simples, évite le jargon. » Ou l’inverse : « Rends ce texte plus formel et académique, ajoute des références, utilise un vocabulaire technique. »

Cas d’usage	Technique recommandée	Template prompt
Génération de code	Zero-shot avec rôle expert + contraintes	« Tu es un expert {langage}. Génère {fonction} qui {spec détaillée}. Format : code commenté + docstring. »
Classification	Few-shot (2-3 exemples)	« Classe selon {catégories}. Ex: Input X → Output Y. Input Z → ? »
Extraction JSON	Few-shot + format strict	« Extrais {champs} en JSON. Ex: Input → {json}. Input réel → ? »
Résumé	Zero-shot avec contraintes	« Résume en {X mots}, niveau {audience}, format {structure}. »
Traduction	Zero-shot + contexte culturel	« Traduis en {langue cible}, ton {style}, adapte références culturelles. »
Raisonnement	Chain-of-Thought	« Résous {problème}. Raisonne étape par étape. »

Erreurs Courantes à Éviter

Même avec les meilleures intentions, on fait tous des erreurs. Voici les pièges dans lesquels je suis tombé (et que vous devriez éviter) :

1. Prompts trop vagues ou ambigus — « Optimise ce code » ne veut rien dire. Optimiser la performance ? La lisibilité ? La mémoire ? Soyez spécifique : « Refactorise pour réduire la complexité temporelle de O(n²) à O(n log n) ».
2. Surcharge de contexte — Envoyer 100 000 tokens de documentation quand 500 suffisent. Résultat ? Latence élevée, coûts explosés, et le modèle perd le fil. Optimisez votre contexte : ne gardez que le strict nécessaire.
3. Oublier de spécifier le format de sortie — Vous voulez du JSON ? Dites-le explicitement. Sinon, l’IA va vous sortir du texte libre, et vous allez galérer à parser. Pire : le format va varier d’un run à l’autre.
4. Ne pas tester avec différents paramètres — Vous testez avec temperature: 0.7 et ça marche. Mais avez-vous essayé 0.2 pour voir si c’est plus stable ? Ou 0.9 pour voir si ça génère plus de créativité ? Testez plusieurs configs.
5. Ignorer l’évaluation des hallucinations — L’IA invente parfois des faits, des noms de bibliothèques, des fonctions qui n’existent pas. Validez TOUJOURS les outputs critiques. Pour du code, exécutez-le. Pour des faits, vérifiez les sources.
6. Utiliser des instructions négatives — « Ne fais pas X » est mal compris par les LLMs. Dites plutôt « Fais Y ». Exemple : « N’utilise pas de boucles » → « Utilise des list comprehensions ou des fonctions vectorisées ».
7. Copy-paste aveugle — Coller le code généré sans le comprendre. Mauvaise idée. Lisez, comprenez, et adaptez. L’IA peut générer du code fonctionnel mais sous-optimal ou non sécurisé.
8. Ne pas itérer — Vous écrivez un prompt, il marche une fois, et vous le mettez en prod. Erreur. Testez sur 20+ inputs variés avant de déployer. Les cas limites vont vous surprendre.

Attention : Les hallucinations sont le risque numéro 1 en production. Ne faites JAMAIS confiance aveuglément. Mettez en place des validations, des tests, et idéalement une review humaine sur les outputs critiques.

Bref, le prompt engineering, c’est comme le code : ça s’améliore par l’itération, les tests, et l’apprentissage de ses erreurs.

Tendances et Évolutions du Prompt Engineering

Le domaine évolue à une vitesse folle. Voici ce qui se profile pour 2026 et au-delà :

Automatic Prompt Engineering (APE) : Des LLMs qui génèrent et optimisent automatiquement leurs propres prompts. Vous décrivez votre objectif en langage naturel, et l’IA crée le prompt optimal pour vous. Google et OpenAI travaillent activement là-dessus. Concrètement, vous pourriez bientôt dire « Je veux un agent qui analyse mes logs serveurs et m’alerte sur les anomalies », et l’IA génère tout le workflow de prompts nécessaires.

Meta-prompting : Des prompts qui définissent comment d’autres prompts doivent être construits. C’est une couche d’abstraction supplémentaire. Exemple : un méta-prompt qui dit « Pour chaque requête utilisateur, génère d’abord un plan d’action, puis exécute chaque étape du plan avec un prompt spécialisé. » On commence à voir ça dans des frameworks comme LangChain et AutoGPT.

Near-infinite memory : Avec les fenêtres de contexte qui explosent (Gemini à 2M tokens, Google annonce viser 10M+ en 2026), on va pouvoir faire du « prompt once, remember forever ». Imaginez charger toute votre codebase une seule fois, et ensuite travailler pendant des heures sans recharger le contexte. Ça change totalement le workflow.

Large Concept Models (LCM) : Les chercheurs bossent sur des modèles qui raisonnent en concepts plutôt qu’en tokens. Ça devrait réduire les hallucinations et améliorer la compréhension profonde. Pour nous, ça voudrait dire des prompts plus simples et plus fiables.

RAG (Retrieval Augmented Generation) : Combiner LLMs avec des bases de connaissances externes. Au lieu de tout mettre dans le prompt, le modèle va chercher les infos pertinentes dans une base vectorielle. C’est déjà très utilisé pour des chatbots documentaires ou des assistants techniques. J’expérimente ça avec Supabase et pgvector : l’IA récupère automatiquement les parties pertinentes de ma doc avant de répondre.

• Agents autonomes plus sophistiqués (multi-step reasoning + tool use)
• Meilleure gestion de la mémoire à long terme (contexte multi-sessions)
• Techniques anti-hallucination intégrées nativement dans les modèles
• Outils no-code pour créer des workflows de prompts complexes
• Spécialisation par domaine (LLMs fine-tunés pour legal, medical, code)

Le futur du prompt engineering, c’est moins de prompting manuel et plus d’orchestration intelligente. On va devenir des architectes de systèmes d’IA plutôt que des rédacteurs de prompts. Et croyez-moi, c’est excitant.

Questions Fréquentes

Qu’est-ce que le prompt engineering ?

Le prompt engineering est la discipline qui consiste à concevoir des instructions optimisées pour les modèles de langage (LLMs) afin d’obtenir des réponses précises, fiables et structurées. Concrètement, c’est l’art de « programmer » l’IA en langage naturel. Au lieu de coder des algorithmes, vous écrivez des prompts qui guident le comportement du modèle. Cette pratique est essentielle en production, car des études montrent qu’un prompt bien conçu améliore la qualité des sorties de 40 à 60% par rapport à une instruction basique. Pour un développeur, c’est comme écrire une fonction bien documentée : clarté, spécificité et structure sont les clés.

Quelle différence entre zero-shot et few-shot prompting ?

Le zero-shot prompting consiste à donner une instruction directe sans fournir d’exemples, en s’appuyant uniquement sur les connaissances préalables du modèle. Le few-shot prompting, quant à lui, fournit 1 à 3 démonstrations concrètes (couples input/output) pour guider le comportement du modèle. Cette deuxième approche améliore l’accuracy jusqu’à 28% et est particulièrement efficace pour forcer un format spécifique (JSON, structure précise) ou un style particulier. Dans la pratique, j’utilise zero-shot pour des tâches simples et universelles (résumés, traductions basiques), et few-shot dès que je veux un contrôle précis sur la sortie (parsing de données, classification avec nuances).

Comment fonctionne le chain-of-thought prompting ?

Le Chain-of-Thought (CoT) prompting demande au modèle de décomposer son raisonnement étape par étape avant de donner une réponse finale. Il suffit souvent d’ajouter l’instruction « Raisonne étape par étape » ou « Let’s think step by step » à la fin du prompt. Cette technique génère des étapes intermédiaires de raisonnement visibles, ce qui améliore drastiquement la capacité du modèle à résoudre des problèmes complexes nécessitant de la logique, des maths ou une analyse multi-étapes. Je l’utilise systématiquement pour générer des scripts de migration de données ou résoudre des bugs logiques : demander à l’IA de lister d’abord les risques et les étapes avant de coder réduit énormément les erreurs.

Quels sont les paramètres importants en prompt engineering ?

Les trois paramètres essentiels sont Temperature (contrôle la créativité), Top-K (limite le nombre de tokens candidats) et Top-P (sampling nucléaire basé sur probabilité cumulée). La température est le plus critique : une valeur basse (0 – 0.2) rend le modèle déterministe et est indispensable pour générer du code, du JSON ou faire des calculs. Une valeur élevée (0.7 – 1.0) introduit de l’aléatoire et de la créativité, utile pour du brainstorming ou de la rédaction littéraire. Top-K (typiquement 20-40) et Top-P (0.9-0.95) affinent la sélection pour éviter que le modèle parte dans des délires improbables. Pour mes workflows en production, je règle souvent : température 0.2, Top-P 0.95, Top-K 30 pour garantir des sorties factuelles et reproductibles.

Comment réduire les hallucinations des LLMs ?

Pour réduire les hallucinations, utilisez la technique self-consistency (générer plusieurs réponses et sélectionner la plus fréquente par majority vote), des prompts structurés avec contraintes claires, et demandez systématiquement des citations de sources. Concrètement, lancez le même prompt 5 fois avec une température modérée (0.5-0.7) et retenez la réponse majoritaire. Complétez avec des instructions explicites : « Base ta réponse uniquement sur les informations fournies dans le contexte. Si tu ne sais pas, dis ‘Je ne sais pas’. » Enfin, évaluez systématiquement les outputs avant mise en production. Pour mes workflows critiques chez WebNyxt (analyse de contrats, extraction de données sensibles), je combine self-consistency et validation humaine : ça réduit les erreurs de 80%.

Qu’est-ce que ReAct prompting ?

ReAct (Reasoning + Acting) est une technique avancée qui combine le raisonnement en langage naturel avec des actions externes comme la recherche web ou l’exécution de code. Le modèle fonctionne dans une boucle itérative : Thought (pensée sur ce qu’il faut faire), Action (appel d’un outil externe), Observation (récupération du résultat), puis répétition jusqu’à résolution complète. Concrètement, ça permet de créer des agents autonomes capables d’interagir avec le monde réel. J’expérimente ça avec n8n et LangChain : des workflows où l’IA décide elle-même quelles API appeler, analyse les résultats, et ajuste sa stratégie en conséquence. Pour automatiser des tâches DevOps (analyser des logs, checker des métriques, redémarrer des services si besoin), c’est redoutable.

Comment choisir la bonne technique de prompting ?

Pour des tâches simples et universelles, utilisez zero-shot. Pour des tâches structurées nécessitant un format spécifique, privilégiez few-shot. Pour des problèmes de raisonnement complexe, optez pour chain-of-thought. Si la tâche nécessite des interactions externes, ReAct est la solution. Plus précisément : zero-shot pour résumés, traductions basiques, questions factuelles simples. Few-shot dès que vous voulez forcer un format (JSON, style précis) ou une classification nuancée. Chain-of-Thought pour les maths, la logique, le debugging, l’analyse multi-étapes. ReAct pour les agents autonomes qui doivent chercher des infos ou exécuter du code. Adaptez aussi selon vos ressources : few-shot et CoT consomment plus de tokens, self-consistency multiplie les coûts par 5-10. En production, je commence toujours par zero-shot, puis je monte en complexité uniquement si nécessaire.

Le prompt engineering est-il pertinent pour tous les modèles LLM ?

Oui, le prompt engineering est applicable à tous les grands modèles de langage comme GPT (OpenAI), Claude (Anthropic), Gemini (Google) ou Llama (Meta). Bien que les comportements puissent varier légèrement selon les modèles (GPT-4 est plus créatif, Claude plus prudent, Gemini excelle en multimodal), les best practices restent universelles : clarté des instructions, fourniture de contexte pertinent, utilisation d’exemples (few-shot), et ajustement des paramètres selon le type de tâche. Certaines techniques peuvent être plus efficaces sur certains modèles (Chain-of-Thought marche très bien sur GPT-4 et Gemini, un peu moins sur des modèles plus petits), mais l’approche générale s’applique partout. Dans mes projets, je teste souvent plusieurs modèles avec le même prompt pour comparer les résultats et choisir le meilleur ratio qualité/coût.

Le Workflow « Super-Prompt » avec Gemini (Mon Préféré)

On arrive à la partie qui a changé mon quotidien de freelance. Vous connaissez le problème du « Context Drift » ? Vous demandez à ChatGPT de refactoriser un fichier, et il oublie que vous utilisez TypeScript ou une convention de nommage spécifique. Deux requêtes plus tard, il génère du code incompatible avec votre stack. C’est l’enfer.

Lee Boonstra propose une solution radicale dans son whitepaper : le Super-Prompt via des fichiers de configuration contextuels. C’est comme créer un « Mini-Moi » virtuel qui connaît votre projet par cœur.

Le Problème du « Context Drift »

Imaginez que vous développez une app Next.js avec TypeScript, Tailwind et Supabase. Vous demandez à l’IA de générer un composant. Premier résultat : du JavaScript vanilla avec inline styles. Vous précisez « Utilise TypeScript et Tailwind ». Deuxième résultat : du TypeScript, mais le composant utilise useState alors que vous travaillez exclusivement en Server Components.

Le problème ? L’IA ne voit qu’un seul fichier, hors contexte. Elle ne sait pas que vous avez des conventions de nommage, une architecture spécifique, des librairies préférées. À chaque requête, vous devez répéter les mêmes consignes. Concrètement, vous perdez 30% de votre temps à corriger des outputs qui ne respectent pas votre stack.

C’est exactement ce qui m’est arrivé sur GymLog. Je devais générer 20 écrans React Native, et à chaque fois, je précisais : « Utilise TypeScript, React Navigation v6, mes custom hooks, mon thème de couleurs ». Au bout du 5ème écran, j’ai craqué. Il fallait une solution systémique.

La Solution GEMINI.md : Votre « Company Handbook »

Au lieu de répéter vos consignes à chaque prompt, vous créez un fichier GEMINI.md à la racine de votre projet. L’IA (via l’extension Gemini pour VS Code ou le CLI) va lire ce fichier en priorité et l’utiliser comme contexte permanent.

Dans mes projets Next.js chez WebNyxt, mon fichier ressemble à ça :

# PROJECT CONTEXT - WebNyxt Client Dashboard

## Stack Technique
- Next.js 14 (App Router, Server Components par défaut)
- TypeScript strict mode
- Tailwind CSS (pas de CSS-in-JS)
- Supabase (auth + database)
- Zustand pour state management client-side

## Règles de Code
- TOUJOURS utiliser Server Components sauf indication contraire
- Pas de useEffect si une Server Action peut le faire
- Typage strict : pas de 'any', utiliser des interfaces
- Nommage : PascalCase pour composants, camelCase pour fonctions
- Async/await pour toutes les opérations asynchrones

## Style & UI
- Composants Shadcn/ui pour l'UI
- Palette : primary=#3B82F6, secondary=#10B981
- Responsive mobile-first
- Dark mode supporté (utiliser class dark:)

## Conventions Fichiers
- Components dans /components/[feature]/
- Server Actions dans /app/actions/
- Types dans /types/
- Pas de barrel exports (index.ts)

Résultat ? Dès que je demande « Crée une page de login », l’IA me sort un code parfaitement aligné avec ma stack : Server Component Next.js 14, formulaire avec Server Action, validation TypeScript strict, styles Tailwind avec ma palette de couleurs, gestion d’erreurs propre. Sans que j’aie à préciser quoi que ce soit.

Plus précisément, j’ai divisé mon temps de génération par 3 et réduit les corrections manuelles de 70%. Entre nous, c’est le genre d’optimisation qui change vraiment la vie d’un dev freelance qui jongle entre 5 projets clients.

Conseil Nicolas : Vous pouvez avoir plusieurs niveaux de contexte. Un GEMINI.md global à la racine du projet, et des fichiers locaux dans chaque sous-dossier pour des contextes plus spécifiques. Par exemple, un GEMINI.md dans /components/admin/ qui précise « Ces composants sont réservés aux admins, ajoute systématiquement un check de permissions. »

Optimiser les Tokens avec .geminiignore

Envoyer tout votre dossier node_modules à l’IA, c’est comme essayer de lire l’annuaire pour trouver un numéro : c’est long, coûteux et inutile. Lee Boonstra insiste sur l’utilisation d’un fichier .geminiignore (comme un .gitignore).

Voici mon .geminiignore standard :

node_modules/
.next/
dist/
build/
.env*
*.log
coverage/
.DS_Store
public/assets/
*.min.js
package-lock.json
yarn.lock

Ça garde votre fenêtre de contexte propre pour ce qui compte vraiment : votre code source. Concrètement, sur un projet Next.js classique, ça réduit le contexte envoyé de 500 000 tokens à 15 000 tokens. Gain de temps de réponse (latence divisée par 3), économie de coûts (vous payez au token), et surtout, l’IA ne se perd plus dans des dépendances tierces.

D’ailleurs, avec la fenêtre de 2M tokens de Gemini, vous pourriez techniquement tout envoyer. Mais franchement, pourquoi polluer le contexte avec du code que vous ne toucherez jamais ? Optimisez.

Intégration dans VS Code

Voici comment j’ai configuré mon workflow quotidien avec l’extension Gemini pour VS Code :

1. Installation — Extension « Gemini Code Assist » depuis le Marketplace VS Code
2. Configuration API — Renseignez votre clé API Gemini (gratuite jusqu’à 60 requêtes/minute)
3. Création du contexte — Ajoutez GEMINI.md et .geminiignore à la racine
4. Raccourcis clavier — J’ai mappé Cmd+Shift+G pour ouvrir le chat Gemini avec contexte automatique

Maintenant, quand je code, je peux :

• Sélectionner du code + Cmd+Shift+G — « Refactorise cette fonction en respectant les conventions du projet »
• Ouvrir un fichier + prompt — « Génère les tests unitaires pour ce composant »
• Multi-fichiers — Sélectionner 3-4 fichiers liés et demander « Ajoute une fonctionnalité X en respectant l’architecture »

L’extension envoie automatiquement le GEMINI.md + les fichiers sélectionnés + votre prompt. Résultat ? L’IA génère du code contextuellement parfait. Je n’ai plus à reformuler mes conventions 10 fois par jour.

Pour être totalement transparent, ça m’a fait passer de 50-60 requêtes ratées par jour (code à corriger manuellement) à moins de 10. Et franchement, sur un projet de 3 mois, ça représente des dizaines d’heures économisées.

Cas d’Usage Code & Debugging

Pour finir, voici trois prompts tirés du whitepaper de Lee Boonstra que j’utilise quotidiennement :

1. Le Traducteur de Code (Bash → Python)

J’ai souvent des vieux scripts Shell illisibles que je veux passer en Python pour la maintenance et la portabilité.

Prompt : « Tu es un expert Python Senior. Traduis ce script Bash en Python idiomatique. Utilise les bibliothèques standard os, pathlib et subprocess. Gère les erreurs avec des blocs try/except explicites. Ajoute des docstrings et du type hinting complet. »

Le résultat est souvent plus propre que l’original, avec gestion d’erreurs robuste et commentaires que j’avais la flemme d’écrire. Bonus : le code Python est beaucoup plus testable.

2. Le Débuggeur Proactif

Quand j’ai une erreur, je ne colle pas juste le traceback. Je colle le code complet + l’erreur + le contexte.

Prompt : « Voici une erreur Python [Traceback complet]. Voici le code concerné [code]. Analyse le problème, explique la cause racine en termes simples, propose le fix avec le code corrigé complet, et suggère une amélioration pour éviter que ce type d’erreur se reproduise (tests, validation, refacto). »

Souvent, l’IA trouve des cas limites (edge cases) auxquels je n’avais même pas pensé. Par exemple, j’avais un bug sur GymLog où une fonction plantait sur des valeurs nulles. L’IA m’a non seulement corrigé le bug, mais suggéré d’ajouter une validation Pydantic en amont pour garantir que les valeurs nulles ne puissent jamais arriver jusqu’à cette fonction.

3. Le Générateur de Documentation

Pour des fonctions complexes ou des modules entiers sans documentation.

Prompt : « Analyse ce module Python [code]. Génère une documentation complète : docstring de module, docstrings de chaque fonction (description, paramètres avec types, valeur de retour, exceptions possibles, exemples d’utilisation). Format Google Style. »

Résultat ? Une doc propre et structurée que je peux directement intégrer. Ça m’a permis de documenter rétroactivement un projet de 15 000 lignes en quelques heures au lieu de plusieurs jours.

Astuce : Pour le debugging, ajoutez toujours le contexte d’exécution (inputs utilisés, état des variables, logs). Plus le modèle a d’informations, meilleures seront ses recommandations. J’ai un script qui capture automatiquement le contexte d’erreur (stack trace + variables locales + derniers logs) et le formate pour l’IA.

L’Itération est la Clé

L’ingénierie de prompt, ce n’est pas une science exacte, c’est du développement itératif. Comme le dit Lee Boonstra : « Everyone can write a prompt, but crafting the effective prompt takes time. »

Mon conseil final ? Ne faites pas confiance aveuglément. Documentez vos prompts. J’ai un fichier Excel (oui, à l’ancienne) où je note mes meilleures structures de prompt pour mes clients chez WebNyxt. Colonnes : Use Case, Prompt complet, Paramètres (temperature, top-p), Performance (accuracy estimée, coût moyen en tokens), Notes (ce qui marche, ce qui marche pas).

Ça me permet de capitaliser sur ce qui fonctionne et de ne pas réinventer la roue à chaque projet. Après 18 mois d’expérimentation intensive, j’ai une bibliothèque de 50+ prompts éprouvés qui couvrent 80% de mes besoins quotidiens.

Alors, la prochaine fois que vous ouvrez votre IDE, ne demandez pas juste à l’IA de « faire le code ». Configurez-la (température, context window, paramètres), donnez-lui du contexte (fichier GEMINI.md, exemples few-shot), et programmez-la pour qu’elle devienne l’extension de votre propre cerveau. C’est là que se trouve la vraie productivité.

Le prompt engineering en 2026, ce n’est plus de la magie, c’est une compétence de développeur aussi importante que maîtriser Git ou écrire des tests. Et franchement, ceux qui l’ignorent vont se faire distancer. Concrètement, un dev qui maîtrise le prompt engineering est 2-3x plus productif qu’un dev qui « chatte » avec l’IA sans méthode. Entre nous, investissez maintenant dans cette compétence, votre futur vous remerciera.

À bientôt pour un prochain deep-dive technique !