Tu n'as jamais choisi ta stack. Ton IA l'a fait pour toi.

Le jour où ton deuxième projet ne ressemble pas au premier

Tu n'es pas développeur, et tu construis ton app avec l'IA. Au début, tout va bien.

Ton agent te fait créer ton premier dépôt git (l'endroit où vit ton code). Il choisit un langage, un framework (la boîte à outils de base sur laquelle ton app est construite), une base de données, une façon de gérer les comptes utilisateurs. Tu ne lui as rien demandé de tout ça. Il a fait des choix, et ces choix sont cohérents entre eux. Ton app tourne.

Trois mois plus tard, ton produit a grossi. Tu as des clients, des commandes, des données à regarder. Tu veux un back-office pour piloter tout ça.

Alors tu fais ce qui paraît logique : un nouveau projet, un nouveau dépôt. Tu ouvres ton agent, et tu lui refais à peu près la même demande que la première fois. "Crée-moi une app d'administration pour gérer mes clients et mes commandes."

Il te construit un back-office. Il marche. Et il n'a rien à voir avec ton app.

Ton app est en TypeScript. Ton back-office est en Python.

Tu ne t'en rends pas compte tout de suite, parce que les deux fonctionnent. Tu t'en rends compte le jour où il faut les faire vivre ensemble.

Le piège, ce n'est pas d'avoir choisi la mauvaise stack. C'est de n'avoir jamais choisi.

Pourquoi l'IA ne fait pas deux fois le même choix

Ce n'est pas un bug. C'est le fonctionnement normal d'un agent.

Quand tu lui demandes de créer un projet, il n'a aucune mémoire de ton premier dépôt. Il ne sait même pas qu'il existe. Il répond à la question posée, avec ce qui lui semble le plus probable pour cette question-là.

Et "le plus probable" dépend des mots que tu emploies. "Une app" et "un back-office" ne déclenchent pas les mêmes réflexes. "Un dashboard", "une API", "un outil interne" non plus. À chaque formulation, son écosystème préféré. Tu changes trois mots, tu changes de langage.

C'est comme si tu faisais venir deux architectes qui ne se sont jamais parlé, à trois mois d'écart, pour construire deux bâtiments sur le même terrain. Chacun fait du bon travail. Mais l'un a posé des prises en 220 volts et l'autre en 110. Les deux maisons sont habitables. Le terrain, lui, est devenu un casse-tête.

Un agent amplifie ce qui existe déjà dans ton projet. Dans un projet vide, il n'y a rien à amplifier. Alors il part de zéro, et zéro n'est jamais le même deux fois.

Ce que ça te coûte, concrètement

Sur le papier, deux projets qui marchent, c'est deux projets qui marchent. Dans la vraie vie, voilà ce que tu viens de t'acheter.

Deux langages. Chaque langage a ses outils, ses bibliothèques, ses pièges. L'IA jongle avec les deux sans effort. Toi, non. Et le jour où tu fais appel à un développeur, il te faut quelqu'un qui maîtrise les deux, ou deux personnes.

Deux chaînes de déploiement à maintenir. Le CI/CD, c'est le mécanisme qui vérifie ton code et le met en ligne à chaque modification. Avec deux stacks, tu en as deux. Deux configurations à comprendre, deux endroits qui peuvent casser, deux séries de réglages à refaire quand un service change ses conditions.

Deux systèmes d'authentification. C'est le plus douloureux. Ton app gère les comptes d'une façon, ton back-office d'une autre. Résultat : soit tu te connectes deux fois, soit il faut construire un pont entre les deux. Et un pont entre deux systèmes de connexion, c'est exactement le type d'endroit où les failles de sécurité s'installent.

Deux façons de déployer. Deux hébergeurs, ou deux configurations chez le même. Deux factures. Deux jeux de mots de passe et de clés à protéger. Deux procédures à connaître quand ça tombe en panne un dimanche soir.

Deux logiques d'architecture. Chaque écosystème a sa façon de ranger les choses. Tu avais commencé à comprendre comment ton app était organisée. Le back-office est rangé autrement. Tout ce que tu avais appris ne sert plus de l'autre côté.

Et il y a le coût qui n'apparaît pas dans la liste : chaque correction se fait deux fois. Une règle métier qui change (un nouveau statut de commande, une nouvelle façon de calculer un prix), c'est deux implémentations, dans deux langages, à garder alignées à la main. Tu en oublieras une. C'est là que naissent les bugs où l'app dit une chose et le back-office en dit une autre.

Le problème, ce n'est pas Python ou TypeScript

Soyons clairs : les deux sont très bien. Python est excellent. TypeScript est excellent. Tu pourrais construire ton produit entier avec l'un ou l'autre, et il tiendrait.

Le problème, ce n'est pas le choix. C'est l'absence de choix.

Une cuisine où chaque tiroir vient d'un magasin différent, ça marche aussi. Chaque tiroir s'ouvre. Mais rien ne s'emboîte, chaque réparation demande une pièce différente, et personne d'autre que toi ne sait où sont les couverts.

Ça vaut aussi dans l'autre sens. Le dernier framework à la mode, celui dont tout le monde parle sur LinkedIn cette semaine, n'est pas une raison de démarrer ton troisième projet dessus. Une stack standard et cohérente, n'importe quel développeur correct la reprend. Une collection de choix brillants pris à des moments différents, personne ne veut la reprendre.

La cohérence vaut plus que la nouveauté. Dans un produit, c'est presque toujours vrai.

Comment fixer ta stack sans être tech

Tu n'as pas besoin de comprendre les technologies pour prendre cette décision. Tu as besoin de l'écrire noir sur blanc, et de la donner à ton IA à chaque fois.

1. Fais décrire ta stack actuelle

Ouvre ton premier projet, celui qui tourne, et pose cette question à ton agent :

Décris-moi la stack de ce projet en dix lignes maximum :
langage, framework, base de données, gestion des comptes utilisateurs,
hébergement, façon de déployer, et comment le code est organisé.
Sois concret, avec les noms exacts et les versions.

Tu obtiens la fiche d'identité de ton projet. Tu n'as pas besoin de tout comprendre. Tu as besoin de la garder.

2. Range-la dans un fichier à la racine

Crée un fichier à la racine de ton projet et colle cette fiche dedans. Les agents lisent ces fichiers automatiquement quand ils travaillent dans ton projet : CLAUDE.md pour Claude Code, AGENTS.md pour Codex et la plupart des autres. Un fichier STACK.md que tu colles toi-même dans la conversation fait aussi le travail.

Ça ressemble à ça :

# Stack

- Langage : TypeScript
- Framework : Next.js
- Base de données : PostgreSQL via Supabase
- Comptes utilisateurs : Supabase Auth
- Hébergement : Vercel
- Déploiement : automatique à chaque push sur la branche main
- Organisation : un dossier par fonctionnalité

Toute nouvelle app ou nouveau service de ce produit utilise cette stack.
Si tu penses qu'un autre choix est meilleur, explique pourquoi et
attends ma validation avant d'écrire du code.

La dernière phrase compte autant que la liste. Elle transforme un choix silencieux en une conversation.

3. Démarre chaque nouveau projet avec cette fiche

Le jour où tu veux un back-office, une API, un outil interne, peu importe : ta première phrase à l'agent, c'est "voici ma stack, ne t'en écarte pas", suivie de la fiche. Avant même de décrire ce que tu veux construire.

Tu viens de faire en trente secondes ce qu'une équipe technique met plusieurs réunions à décider.

4. Demande-toi si tu as vraiment besoin d'un nouveau projet

C'est la question que personne ne se pose, et c'est souvent la bonne.

Un back-office, dans la plupart des cas, c'est une section de plus dans ton app existante. Mêmes utilisateurs, même base de données, mêmes règles métier. Seule différence : des pages réservées à toi et ton équipe. Pas besoin d'un nouveau dépôt, d'un nouvel hébergement ni d'une nouvelle connexion.

Créer un projet séparé est une décision, pas un réflexe. Demande à ton agent : "est-ce que ce back-office peut vivre dans le projet existant ?". Neuf fois sur dix, la réponse est oui, et tu viens d'éviter tout le problème.

Et si c'est déjà trop tard ?

Tu as lu jusqu'ici avec un pincement, parce que tu as déjà deux stacks. Ça arrive à beaucoup de monde, et non, il ne faut pas tout réécrire demain matin.

Désigne une stack principale. Celle où vivent tes utilisateurs et l'essentiel de ton code. C'est elle qui gagne.

Gèle l'autre. Plus aucune nouvelle fonctionnalité de ce côté-là. Elle continue de tourner, elle ne grossit plus. Chaque nouveauté se construit dans la stack principale.

Rapatrie au fil de l'eau. Quand tu dois toucher un morceau du projet gelé, c'est le moment de le refaire de l'autre côté, plutôt que de le corriger sur place. Le déménagement se fait pièce par pièce, sans jour J.

Et sois honnête sur ce qui mérite de rester. Un script qui tourne une fois par mois pour envoyer un export, en Python, dans son coin, n'est pas un problème. Le problème, c'est deux applications vivantes, avec des utilisateurs, qui doivent évoluer ensemble.

Le seul cas où changer de stack se défend

Il existe. Ta stack ne sait vraiment pas faire une chose dont tu as besoin, ou tu recrutes une équipe qui maîtrise autre chose. Dans ce cas, tu changes, et tu changes pour tout le produit, avec un plan.

Ce qui ne se défend pas, c'est de changer parce qu'un nouveau framework sort, ou parce que l'agent en avait envie ce jour-là. Tu ne changes pas de langue à chaque nouvelle pièce de ta maison.

À retenir

• Ton IA choisit une stack à chaque nouveau projet, et rarement deux fois la même. Si tu ne décides pas, elle décide à ta place.
• Deux stacks, c'est deux langages, deux chaînes de déploiement, deux systèmes de connexion, et chaque correction faite deux fois.
• Fais décrire ta stack, range-la dans un fichier à la racine, et démarre chaque projet en la collant à ton agent.
• Avant de créer un nouveau dépôt, demande si ça peut vivre dans le projet existant. Souvent, oui.
• La cohérence vaut plus que le dernier framework à la mode.

Tu n'as pas besoin de savoir coder pour prendre cette décision. Tu as juste besoin de la prendre.

Tu veux un produit qui tient d'un seul tenant ?

C'est mon travail : construire vite avec l'IA, sur une stack décidée, cohérente, qu'un autre développeur pourra reprendre après moi. Si tu cherches quelqu'un pour construire ou reprendre ton produit, découvre mon offre de développement sur mesure.

Tu as déjà deux projets qui ne se parlent pas et tu ne sais pas lequel garder ? Réserve un audit : en 3 jours, tu sais ce qui est solide, ce qui est risqué, et quoi corriger en premier.

Et pour recevoir ce genre d'articles, inscris-toi à la newsletter. Pas de spam, juste ce qu'il faut savoir.