Vous êtes l'architecte, l'IA est le bâtisseur

Quand vous construisez avec l'IA, vous êtes l'architecte et l'IA est le bâtisseur. Vous possédez chaque décision coûteuse à changer plus tard — quelles données existent, comment elles se relient, qui peut voir quoi, quelle qualité est livrée. L'IA exécute ces décisions en code. Brouillez cette ligne et votre produit finira par s'effondrer.

C'est le modèle mental qui décide si les outils de code par IA font de vous un danger ou vous libèrent. Pas « l'IA est le développeur et je suis le product manager ». Pas « nous codons ensemble comme des partenaires ». Vous concevez. L'IA construit. J'ai appris cette répartition à mes dépens — l'histoire d'origine, avec la falaise des trois mois où les produits bâtis par l'IA meurent en silence, est dans le piège du vibe coding. Cet article en est la moitié pratique : exactement quelles décisions sont les vôtres, lesquelles sont celles de l'IA, et les moments où vous devez résister.

Que veut dire concrètement « vous êtes l'architecte » ?

Pensez à la construction d'une maison. L'architecte prend les décisions qui touchent toute la structure : où la maison s'implante sur le terrain, combien d'étages, quelles fondations, où passent les murs porteurs, comment l'eau et l'électricité circulent. Ces décisions ne se changent pas facilement une fois le chantier lancé. Le bâtisseur exécute cette vision — coule les fondations exactement comme spécifié, monte les murs d'après le plan. Le bâtisseur est incroyablement compétent. Mais il exécute un plan ; il ne le crée pas.

Dites maintenant à un bâtisseur « construis-moi une maison » sans aucun plan. Vous obtiendrez quelque chose. Cela tiendra peut-être même debout et sera joli au début. Mais les fondations ne supporteront pas l'étage que vous voudrez plus tard, et la plomberie sera au mauvais endroit pour votre cuisine. Vous obtenez une structure qui marche jusqu'au jour où vous lui demandez de faire quelque chose pour quoi elle n'a pas été conçue. C'est, en une phrase, la plupart des logiciels bâtis par l'IA.

La matrice de décision : quels choix sont les vôtres, lesquels sont ceux de l'IA

Voici la répartition du travail, rendue concrète. Tout ce qui est à gauche est à vous. Tout ce qui est à droite est délégué :

Remarquez ce qui manque dans la colonne de l'IA : une seule décision. L'IA propose ; vous disposez. Et la décision d'architecte au plus fort levier est de concevoir vos données avant vos écrans — cette méthode a son propre article : le développement database-first.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Les trois casquettes de tout architecte solo

Casquette un : architecte système. Vous décidez de la forme des données. Quelles entités existent, comment elles se relient, si chaque enregistrement est rattaché au client qui en est propriétaire, quel historique est conservé. Ce sont des questions business en habit technique — et vous connaissez votre métier mieux que n'importe quelle IA.

Casquette deux : product manager. Vous décidez de ce qui est construit et, plus important encore, de ce qui ne l'est pas. Les fondations avant les fonctionnalités. Aucun « plus » facultatif dans la version un. Les priorités vous appartiennent : la connexion avant l'analytique, l'analytique avant tout ce qui est avancé. L'IA construira volontiers tout ce que vous demandez, dans n'importe quel ordre — c'est précisément pourquoi l'ordre doit venir de vous.

Casquette trois : assurance qualité. Vous décidez si le travail est assez bon. Suit-il vos modèles ? Est-il sécurisé ? Survivra-t-il à de vrais clients ? C'est vous qui dites « ça crée de la dette, refais-le » — et vous qui dites « c'est prêt pour la production, livre-le ».

Cinq moments où l'IA va vous tester — résistez

L'IA vous suggérera des choses qui sonnent bien et violent votre architecture. Cinq signaux doivent déclencher un arrêt automatique :

1. « Par simplicité… » — traduction : « laisse-moi créer de la dette technique ». La simplicité d'aujourd'hui est la complexité de demain. Exigez la bonne structure.
2. « Pour la performance… » — exigez des preuves. S'il n'y a pas de problème mesuré, il n'y a rien à optimiser. L'optimisation prématurée est la façon dont les systèmes propres pourrissent.
3. « Correctif rapide… » — les bidouilles deviennent permanentes. Dites non, et demandez plutôt la cause racine.
4. Graver les listes d'options dans le code. Statuts, catégories, types — l'IA adore les coder en dur. Gardez-les comme des données modifiables, pour pouvoir ajouter ou renommer des options sans toucher au code.
5. Fourrer des enregistrements liés dans un seul champ fourre-tout. Si des données sont liées, elles ont besoin d'une vraie relation — pour pouvoir être recherchées, connectées et vérifiées. Un champ fourre-tout ne fait rien de tout cela.

Chacun de ces cas est apparu pendant que je construisais FIKR Space, une plateforme qui a grandi jusqu'à 964 tables de base de données. L'IA voulait des listes de statuts codées en dur ; je les ai forcées à vivre comme des données modifiables. L'IA voulait des valeurs dupliquées « pour la performance » ; j'ai exigé une source unique de vérité, avec plus de 90 % des tables entièrement normalisées et chaque exception documentée. Résister n'était pas un événement occasionnel. C'était le métier.

Comment les architectes parlent à l'IA

Comparez deux prompts. Le vibe coder écrit : « Construis une page de profil utilisateur. » L'IA doit maintenant deviner quelles données afficher, d'où elles viennent, ce qui est modifiable et quel modèle suivre. Elle devinera différemment à chaque fois, et votre produit devient un patchwork de suppositions.

L'architecte écrit le plan : quelles sources de données alimentent la page, quelles sections apparaissent, exactement ce que l'utilisateur peut modifier, quelle permission cela exige, quels composants existants réutiliser, et comment se comportent le chargement et les erreurs. La même fonctionnalité. Mais maintenant l'IA sait précisément quoi construire et comment — et le résultat correspond à tout le reste de ce que vous avez construit. Le prompt se lit comme un plan parce que c'en est un.

Les trois niveaux de la pensée architecturale

Niveau un — la fonctionnalité : « J'ai besoin d'un dashboard, donc je construis un dashboard. » Une fonctionnalité à la fois, sans penser à la façon dont elles se connectent. C'est le vibe coder.

Niveau deux — le produit : « Je construis un produit avec des utilisateurs, des équipes et des projets — comment se relient-ils ? » Mieux. Les relations sont conçues. Mais l'échelle et la sécurité restent des arrière-pensées.

Niveau trois — le système : « Je construis quelque chose qui doit isoler les données de chaque client, tenir des pistes d'audit, survivre à la croissance et accepter de nouvelles fonctionnalités sans refonte. » L'échelle, la sécurité et la cohérence sont décidées dès le premier jour.

Le niveau trois est celui où vous devez opérer — et il n'exige pas un diplôme d'informatique. Il exige de penser en systèmes, ce que font chaque jour les professionnels expérimentés de l'entreprise. Vos années à regarder des systèmes de grandes entreprises réussir et échouer sont votre qualification.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Quelles décisions ne dois-je jamais déléguer à l'IA ?

Tout ce qui est coûteux à changer plus tard : la façon dont vos données sont structurées et reliées, qui accède à quoi, les modèles que tout suit, ce qui est construit et dans quel ordre, et le niveau de qualité pour livrer. L'IA exécute ces décisions brillamment. Elle ne devrait jamais les prendre.

Faut-il être technique pour jouer le rôle d'architecte ?

Non. Les décisions d'architecture sont des décisions business déguisées : quelles choses existent dans votre système, comment elles se relient, quelles règles s'appliquent, qui voit quoi. Vous les décrivez en langage courant ; l'IA les traduit en code. La connaissance du domaine compte bien plus que la compétence en code.

Que se passe-t-il si je laisse l'IA prendre les décisions d'architecture ?

Ça marche — au début. Puis les modèles dérivent, le même fait vit à trois endroits et se contredit, les données des clients ne sont pas correctement isolées, et chaque nouvelle fonctionnalité devient plus difficile à ajouter. Finalement, vous reconstruisez. Les décisions de l'architecte sont précisément celles que l'IA optimise à la baisse.

Comment résister à une suggestion de l'IA ?

Soyez précis, pas vague. Nommez ce qui ne va pas, expliquez pourquoi, dites exactement ce que vous voulez à la place, et demandez à voir le résultat mis en œuvre. « C'est faux, corrige » n'apprend rien à l'IA ; une correction précise vous donne un travail de qualité production en un seul passage.