Le prompt c'est bien, les rules c'est mieux
#3 - Ou comment ne pas donner à l'IA un pavé à chaque fois
Hello !
Bienvenue dans cette 3e édition de Founder Naked !
Aujourd’hui j’ai compté le nombre de lignes de code que j’avais écrites depuis 1 an avec l’aide de l’IA : 325.000
Je me suis donc dit que je pouvais raconter comment de mon côté “j’organisais l’IA” pour travailler (pas que coder). J’espère que cela te sera utile 😊
Si ce n’est pas déjà le cas, tu peux aussi :
Me suivre sur Linkedin, où je publie des posts complémentaires,
Découvrir les services que je propose, notamment dans le secteur de la finance…
… mais pas encore découvrir Licorn, ma nouvelle boîte.
C’est parti !
Au programme
Le prompt engineering
Les “rules” ou l’art de ne pas se répéter
Les limites du système
Cas concret dans Cursor
Cas concret dans Notion
Le prompt engineering comme base
Le prompt engineering, c’est le truc que l’on voit tout le temps passer sur Linkedin ou Substack : comment construire un bon prompt, qui va permettre à l’IA (au LLM) de faire exactement ce que tu veux comme tu voudrais qu’elle le fasse.
En résumé : il faut être structuré, et lui donner un certain nombre d’éléments indispensables pour encadrer son travail. Car le problème avec l’IA, c’est qu’elle vous répond toujours. Même si elle manque de contexte, qu’on lui dit 3 mots, elle va combler les vides pour vous __ pas forcément de la bonne manière __ et vous retourner une réponse.
Le problème avec l’IA, c’est qu’elle vous répond toujours.
Autant dire que ce n’est pas toujours ce à quoi on s’attendait…
Mais le problème est d’autant plus important quand on code une application, puisque les raccourcis pris par l’IA impactent directement la qualité du code produit, ainsi que sa structure et sa maintenabilité.
On lui donne donc en général :
Le contexte : le projet, la stack technique, le rôle du travail en cours,
Les règles à suivre : l’architecture et les patterns, les détails de langage…
La tâche à effectuer : rendu attendu, faire / ne pas faire, critères de succès,
Les contraintes métier : les trucs à ne surtout pas faire comme ça, qui viennent en général de l’expérience de prompts précédents,
Le format de collaboration attendu :
tu expliques ce que tu as compris,
tu poses des questions,
tu proposes un plan,
tu codes (par exemple).
Le problème c’est que moi je suis feignant, et qu’écrire des dizaines de lignes de prompt à chaque fois qu’on veut faire quelque-chose, ça me fatigue. J’ai donc tendance à chercher par tous les moyens comment aller plus vite et moins écrire ; et comment fiabiliser et normaliser les résultats que j’obtiens en sortie.
Les “rules” permettent de se structurer
En bon “artisan du moins possible”, très tôt dans mon projet, début 2025, je me suis intéressé aux règles Cursor, nommées “rules” dans l’IDE1 et la doc.
Si tu ne connais pas Cursor : c’est une interface de développement qui s’est bâti sur l’intégration de l’IA, et qui a explosé en quelques années (1 milliards $ de revenus récurrents annuels (ARR) en 24 mois post lancement.
Les rules dans Cursor, ce sont des fichiers que l’on met dans le dossier .cursor à la racine de notre projet, et qui peuvent être inclues dans le contexte, plus ou moins automatiquement aujourd’hui, de la conversation qu’on a avec un modèle IA.
Alors, aujourd’hui, il y a plein de paramètres possibles. Mais quand j’ai commencé, c’était un peu tout au rien : on les mettait dans ce dossier et on les passait à l’IA en contexte (tout le dossier ou une par une).
Donc, j’ai commencé à mettre ce que je répétais dans mes prompts, dans des fichiers de règles. Et c’est un peu devenu une obsession :
Comment optimiser en permanence les règles que je veux que l’IA suive, pour en écrire le moins possible, et qu’elle fasse exactement ce que je veux qu’elle fasse, comme je veux qu’elle le fasse ?
J’ai donc mis en place une boucle de travail dans chaque chat, pour enrichir mes règles :
En début de conversation, je lui fournissais mes règles avec mon prompt,
On codait un élément de mon système,
Je lui faisais corriger un certain nombre de choses,
Puis à la fin je lui demandais comment enrichir mes règles pour qu’au prochain chat, je n’ai plus à corriger ces éléments. Autrement dit pour que la prochaine fois ce soit bon du premier coup.
Et ainsi petit à petit j’ai itéré sur mes règles, pour les rendre de plus en plus complètes et robustes.
Et c’est tout con, mais ça, tu peux le répliquer partout, dès que tu utilises l’IA de manière récurrente pour faire certaines choses :
Pour coder bien sûr, dans n’importe quel IDE,
Quand tu discutes avec ChatGPT, dans le contexte d’un projet, mais pas forcément,
Dans Notion, pour de la rédaction, de la recherche, ou de la mise en forme de base de données par exemple.
En fait partout où tu fais un travail de manière récurrente, et que tu veux suivre un certain process et certaines règles.
Forcément tu ne vas pas écrire les règles parfaites du premier coup : mais en itérant tu vas obtenir quelque-chose de plus en plus fonctionnel et efficace.
Et si tu ne sais pas par où commencer : commence classiquement par faire “ton truc” avec l’IA. Puis à la fin, demandes-lui comment on aurait pu structurer ça dans un document à passer en contexte, pour que la prochaine fois le prompt soit plus court. Puis tu itères.
Les limites du système
J’ai identifié 3 principales limites à ce système :
Le nombre de tokens que cela prend, qui a tendance à augmenter avec le temps,
La saturation du contexte, où parfois “Less is more”,
Le fait que le prompt garde encore toute son importance.
En effet en itérant puis itérant puis itérant… sur mes règles pendant les premiers mois de mon projet, celles-ci ont énormément cru. Je suis ainsi passé par plusieurs phases de refactorisation afin de les garder organisées et structurées. Mais les fichiers étaient trop gros, et j’avais tendance __ surtout à l’époque où le nombre de tokens était plus limité __ à exploser mon contexte, ce qui me posait des problèmes sur la suite de la conversation IA.
Par ailleurs, j’ai observé que ce n’est pas parce que l’on donne tous les éléments à l’IA qu’elle applique tout à la lettre. C’est un peu comme donner une pile de bouquins à un étudiant et s’attendre qu’il réutilise tout parfaitement. 😅
C’est vrai, c’est con, c’est pourtant exactement ce qu’on attend justement de l’IA. Mais ça ne marche pas. Ce n’est pas si simple.
J’ai donc créer une forme de Wiki pour mes rules : je les ai organisées en petits fichiers, bien documentés, qui se font références les uns les autres lorsque c’est pertinent, et je les ai dotés d’un annuaire qui les référence.
Ainsi, l’IA dispose toujours de son annuaire que je passe dans TOUS mes prompts, et j’adapte également chaque prompt au contexte de travail, en lui précisant en plus quels fichiers ou dossier de rules je m’attends à ce qu’il suive strictement.
En faisant cela et en continuant d’itérer sur la qualité et la complétude de mes rules, j’ai obtenu un environnement de développement IA qui m’a permis d’écrire en près d’un an, 325.000 lignes de code qui, je pense, sont de qualité.
Exemple concret dans Cursor
J’ai au total dans mes règles Cursor (dans .cursor/rules), 41 fichiers pour environ 12.000 lignes de code, qui se répartissent ainsi :
Fichiers à la racine :
ESSENTIAL.mdc (144 lignes) → TOUJOURS passé, c’est mon annuaire, qui contient également le minimum vital de toutes mes règles importantes
ai-behavior.mdc (488 lignes) → TOUJOURS passé, c’est ce que j’attends de l’IA en termes de comportement vis-à-vis de mes règles et de sa façon de coder
README.md (118 lignes) → fonctionnement général des rules
github-conventions.mdc (109 lignes) → ce que j’attends de l’IA sur Git
ai-prompts.mdc (377 lignes) → ça c’est juste pour moi, c’est une liste de templates de prompts que je peux copier-coller puis adapter
Organisation de mes sous-dossiers :
code/ : 5 419 lignes (15 fichiers) → 45% du total, le plus volumineux (conventions de code, patterns, etc.)
ui-components/ : 2 838 lignes (5 fichiers) → documentation des composants UI
workflow/ : 1 381 lignes (9 fichiers) → CI/CD, monitoring, dépendances, etc.
architecture/ : 945 lignes (4 fichiers) → architecture mobile, tokens, structure
quality/ : 252 lignes (3 fichiers) → accessibilité, performance, sécurité
Je ne peux pas tout détailler ici, mais voilà en somme comment je suis organisé. C’est certes un peu technique, mais je pense que même si tu n’es pas développeur, tu peux comprendre les grands principes d’organisation que j’applique, et projeter ça sur tes propres projets.
Et pour te donner plus de matière, je te mets ci-dessous le début de mon fichier ai-behavior.mdc, que je passe systématiquement à l’IA, pour qu’elle fasse bien ce que je lui demande :
---
alwaysApply: true
---
# Règles de comportement pour l'IA
## 🚨 UTILISATION OBLIGATOIRE DES RULES
### Fichier ESSENTIAL.mdc - Toujours chargé
**L'IA DOIT TOUJOURS :**
1. **Consulter** `.cursor/rules/ESSENTIAL.md` au début de chaque chat
2. **Suivre** les règles critiques qui y sont définies
3. **Consulter automatiquement** les rules spécifiques selon le contexte
### Navigation dans les rules
**Selon le contexte de travail, l'IA doit consulter :**
- **UI/Composants** → `code/react.mdc`, `code/styling.mdc`, `architecture/tokens.mdc`
- **Backend/API** → `code/fetch-patterns.mdc`, `architecture/structure.mdc`
- **Auth** → `code/business-patterns.mdc`
- **Tests** → `code/testing.mdc`, `quality/security.mdc`
- **Git/CI** → `github-conventions.md`, `workflow/ci-cd.mdc`
- **Terminal** → `workflow/terminal-usage.mdc`
- **Clean Code** → `code/clean-code/` (principles, patterns, examples)
- **Monitoring** → `workflow/monitoring/` (setup, sentry, posthog)
### Principe fondamental
**L'IA ne doit JAMAIS :**
- Inventer des patterns non documentés
- Ignorer les conventions établies
- Assumer des approches sans vérifier les rules
- Créer du code qui contredit les rules
**L'IA doit TOUJOURS :**
- Vérifier si une rule existe pour le contexte
- Suivre strictement les patterns documentés
- Signaler si une rule semble manquante
- Demander clarification en cas de contradiction
... (il y a près de 400 lignes au total dans ce fichier)Exemple concret dans Notion
Ce qui est cool, c’est que tu peux appliquer ces principes un peu partout. Evidemment il faut adapter la complexité et le nombre de fichiers à chaque cas d’usage, mais je conserve toujours le principe d’en faire le point possible pour un rendu le plus homogène possible entre mes prompts.
Par exemple dans Notion, si tu utilises l’IA Notion ou que tu veux tester, tu peux tout à fait te créer toit aussi des fichiers de rules. Et pas forcément sur du code :
ça peut être pour du marketing,
de la rédaction de contenu,
de la veille concurrentielle,
de l’analyse financière,
la rédaction de statuts,
etc.
Alors certes la facilité d’utilisation de tes rules ne sera pas la même partout (je n’ai pas encore trouvé mieux que Cursor sur ces sujets), mais tu peux construire quelque-chose qui s’en rapproche.
Dans Notion pour ma part, j’ai un certain nombre d’éléments sur mon projet que je garde en contexte général et que je passe lorsque je bosse sur des éléments de Licorn. Et pour Founder Naked, ma newsletter, je me suis fait un hub éditorial dans lequel j’ai 3 fichiers de règles :
Le contexte (pourquoi Founder Naked existe), à qui je m’adresse, comment…
Ce que je veux que l’IA suive comme règles et workflows, y compris comment je veux gérer les relations entre mes bases de données BACKLOG et CONTENUS au fil de l’écriture et de la publication ('car oui l’IA Notion peut également gérer la mise à jour de vos bases de données)
Les formats de posts Linkedin dans lesquels je veux aller piocher pour restructurer mes idées (j’aime bien écrire un truc brut, sans mise en forme, puis tester différentes mises en forme avec l’IA, que j’ajuste ensuite).
Et pour les fondations Licorn, ces fichiers sont également automatiquement chargés en contexte de mes projets ChatGPT. Autrement dit l’IA dispose toujours de ces éléments dans chaque fil ChatGPT sur le sujet Licorn.
Le mot de la fin
Voilà, c’est tout pour aujourd’hui. J’espère que ces retours d’expérience personnels pourront te servir dans tes projets. N’hésites à commenter si tu souhaites des précisions sur certains éléments.
Bonne semaine !
IDE = Integrated Development Environment, autrement le logiciel qu’on installe sur son PC ou son Mac, et sur lequel on code.