1. Outils utilisés

Quatre outils IA ont été mobilisés pour cet article, chacun avec un rôle distinct :

• Claude (Anthropic) — modèle Claude Opus 4.5, pour l’exploration de la thèse, la structuration et les passes de rédaction.
• Perplexity — pour la recherche initiale sur l’état du marché SaaS et l’identification des sources primaires (BetterCloud, Productiv, etc.).
• Claude Code — utilisé comme illustration vivante de la thèse : c’est l’outil avec lequel j’ai construit Project OS, le cas d’usage central de l’article.
• Grammarly — relecture finale sur la cohérence syntaxique française.

L’usage combiné de ces outils a réduit le temps de production de ce qui aurait pris une semaine en mode classique à environ huit heures effectives réparties sur trois jours.

2. Exploration créative

Le point de départ était une intuition personnelle : depuis que j’utilise Claude Code, je construis moi-même des outils que j’aurais payés 30 à 50 euros par mois avant. Mais l’intuition ne suffit pas pour un article. Il fallait la transformer en thèse défendable.

J’ai ouvert une session avec Claude pour explorer la question sous différents angles :

• L’angle technique : comment les LLM ont changé l’accessibilité du code (intéressant mais trop pédagogique)
• L’angle business : combien coûte vraiment une stack SaaS moyenne (retenu comme appui chiffré)
• L’angle culturel : la fin du « no-code » comme idéologie (intéressant mais trop méta)
• L’angle pratique : ce que ça change pour un Growth Engineer en 2026 (retenu comme cadre principal)

La combinaison des deux angles retenus a donné l’architecture finale : un constat chiffré sur le SaaS (le problème), une démonstration personnelle (la solution), et une analyse des conditions qui rendent ce choix viable aujourd’hui.

3. Planification

L’article devait répondre à trois questions, dans cet ordre précis :

1. Pourquoi la question se pose maintenant et pas il y a cinq ans ?
2. Quel est le vrai coût caché du SaaS empilé ?
3. Quand construire soi-même devient-il une option crédible (et quand ça ne l’est pas) ?

J’ai demandé à Claude de proposer trois structures différentes pour articuler ces questions. Celle retenue mélange un constat ouvert, une enquête chiffrée, une démonstration par l’exemple, et une grille de décision pratique.

Point important : j’ai exigé qu’aucune statistique ne soit citée sans source vérifiable. Cette contrainte a guidé toute la phase de recherche et a conduit à abandonner plusieurs chiffres « plausibles mais non sourcés » suggérés par l’IA.

4. Rédaction

La rédaction s’est déroulée en quatre passes successives, avec une discipline particulière sur la vérification des sources :

Passe 1 — Première version (Claude). Brouillon complet généré à partir du plan validé, avec des marqueurs explicites [STAT À VÉRIFIER] partout où une donnée chiffrée apparaissait.

Passe 2 — Vérification des sources (Perplexity + humain). Chaque marqueur a été remplacé par une statistique sourcée. Le chiffre central de l’article (106 SaaS apps en moyenne par entreprise) vient du rapport BetterCloud State of SaaSOps 2024, vérifié en lecture directe. Plusieurs chiffres initiaux ont été abandonnés faute de source primaire.

Passe 3 — Injection personnelle (humain). J’ai réécrit toutes les sections qui touchent à Project OS, en y intégrant mes propres décisions techniques, mes apprentissages, et les anecdotes que Claude ne pouvait pas connaître.

Passe 4 — Polissage final (Claude + Grammarly). Resserrement du texte, suppression des répétitions, vérification syntaxique. Aucune intervention sur les idées ou la structure à ce stade.

5. Éthique et sources

La discipline éthique a été particulièrement forte sur cet article, parce que toute la thèse repose sur des chiffres. Quatre règles strictes :

• Aucune statistique générée par IA n’a été conservée sans vérification. Une première version mentionnait « 250 SaaS apps par entreprise en moyenne ». Aucune source primaire n’a confirmé ce chiffre. Il a été remplacé par les 106 du rapport BetterCloud, vérifiables.
• Liens vers sources primaires uniquement. Aucun lien vers des articles intermédiaires qui citeraient d’autres articles. Soit le rapport originel, soit on enlève l’affirmation.
• Pas de citation inventée. Toutes les citations attribuées dans l’article sont issues de sources publiques vérifiables.
• Distinction claire entre opinion et fait. Toute affirmation non sourcée est explicitement présentée comme mon opinion ou mon expérience, jamais comme un fait établi.

Cette discipline a allongé le temps de production d’environ 30%, mais c’est le seul moyen de défendre la crédibilité d’un article qui s’appuie sur du chiffre.

6. Exemples de prompts utilisés

Trois prompts particulièrement structurants pour cet article.

Je veux écrire un article qui défend l'idée suivante : en 2026, grâce aux LLM
comme Claude Code, construire ses propres outils internes est redevenu une
option viable face au SaaS empilé. Aide-moi à transformer cette intuition en
thèse défendable. Quels sont les contre-arguments les plus solides que je
devrai désamorcer ? Quels chiffres pourraient soutenir la thèse, s'ils
existent ?

Rédige une première version de l'article à partir de ce plan. Règle absolue :
chaque fois que tu cites une statistique, marque-la avec [STAT À VÉRIFIER]
suivi de ta meilleure estimation de la source primaire probable. Ne cite
jamais un chiffre comme acquis sans cette balise. Si tu n'es pas sûr d'une
source, dis-le explicitement.

Voici la section sur Project OS. Réécris-la en gardant la structure mais en
intégrant ces éléments personnels : j'ai construit l'outil en 3 semaines avec
Claude Code, sur une stack Next.js + Supabase, parce que Asana ne me
permettait pas de coller exactement à mon workflow solo. Garde un ton concret
et pratique, pas théorique.

Note rédigée par Anas Essalhi — MBA DMB, EFAP Paris — Juin 2026