5 piliers du logiciel de production :le cadre pour l'IA

Les 5 piliers du logiciel de production séparent le code qui tourne du logiciel qui fonctionne et du produit qui passe à l'échelle : architecture et réflexion sur la base de données, conception du système, sécurité et confiance, réflexion produit, et savoir travailler avec l'IA elle-même. L'IA écrit le code en quelques secondes. Les piliers sont les vingt ans de jugement qu'elle ne peut pas fournir — condensés pour qu'un fondateur non technique les applique dès le premier jour.

C'est le cadre qui sous-tend tout ce que j'enseigne sur la construction avec l'IA. L'IA peut générer des milliers de lignes de code, mais elle ne peut pas comprendre les conséquences business des décisions d'architecture, prévoir comment la dette technique s'accumule, savoir quand enfreindre ses propres règles, anticiper les cas limites que personne n'a décrits, ni arbitrer entre vitesse et exactitude selon le contexte. Le code est gratuit. Voici ce que vous avez réellement besoin de savoir.

Pilier 1 : architecture et réflexion sur la base de données

La fondation — si elle est mauvaise, tout le reste est bâti sur du sable. Les règles de base : organisez vos données pour que rien ne soit stocké deux fois (restez normalisé à plus de 90 %, et dénormalisez délibérément, jamais par accident). Mettez une colonne d'organisation sur chaque table dès le premier jour — ajouter le multi-tenant plus tard, c'est toucher à 964 tables ; demandez-moi comment je le sais. Activez la row-level security pour que la base de données elle-même refuse de montrer les données d'un client à un autre, même quand votre code a des bugs. Ne supprimez jamais vraiment rien — marquez comme supprimé pour que les utilisateurs puissent annuler. Tracez qui a créé et modifié chaque enregistrement. Indexez tout ce que vous interrogez, car votre application est rapide avec 100 enregistrements et inutilisable avec 100 000 sans index.

Chacune de ces règles est invisible dans une démo et vitale en production. Et l'IA les sautera presque toutes si vous ne les demandez pas explicitement.

Pilier 2 : conception du système et passage à l'échelle

La façon dont votre code est organisé détermine la vitesse à laquelle vous pouvez avancer. L'épine dorsale, c'est la séparation des responsabilités : l'écran parle à un hook, le hook parle à un service, seul le service parle à la base de données — ne sautez jamais de couche (j'ai consacré un article entier à ce schéma en 3 couches). Autour de cette épine : chaque écran gère les états de chargement, d'erreur et de vide, pas seulement celui de succès ; tout ce qui est lent s'exécute en arrière-plan au lieu de faire attendre les utilisateurs ; les données se chargent par pages de 20 à 50 éléments plutôt que d'un seul coup ; les résultats qui changent rarement sont mis en cache ; et les opérations se comportent de la même façon que l'utilisateur clique une fois ou, par impatience, cinq fois.

Rien de tout cela n'est exotique. C'est la différence entre une application qui impressionne dans un enregistrement d'écran et une application qui survit à son centième client.

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

Pilier 3 : sécurité et confiance

Les utilisateurs vous confient leurs données ; le troisième pilier consiste à ne pas trahir cette confiance. L'authentification répond à la question « qui est cette personne » — l'autorisation répond à « que peut-elle faire », et ce ne sont pas les mêmes vérifications. La défense fonctionne par couches : la base de données applique la row-level security, le service vérifie les permissions métier, l'API valide chaque requête, et l'interface masque ce qu'un utilisateur ne peut pas toucher — ainsi, quand une couche cède, les autres tiennent. Chaque saisie utilisateur est validée avant d'être utilisée. Chaque secret vit dans la configuration, jamais dans le code. Et la saisie utilisateur n'est jamais collée directement dans les requêtes de base de données, c'est ainsi que les attaquants suppriment vos tables.

L'IA est la plus dangereuse ici, car un code non sécurisé ressemble exactement à un code sécurisé quand il s'exécute. Ça marche, ça se démontre, et ça fuit.

Pilier 4 : réflexion produit

Le code fonctionne ; les produits se livrent. Le quatrième pilier, c'est tout ce que ressentent les utilisateurs : les fonctionnalités importantes passent derrière des flags que vous pouvez désactiver sans redéployer, si bien qu'un lancement raté se règle d'un interrupteur plutôt que dans l'urgence. Quand un service tiers tombe, la fonctionnalité se dégrade proprement au lieu de faire tomber toute l'application. Chaque action de l'utilisateur reçoit un retour — un indicateur de chargement, une confirmation, une erreur avec possibilité de réessayer. Et quand vitesse et exactitude s'opposent, l'exactitude l'emporte : rapide mais faux est pire que lent mais juste, car des données corrompues sont le seul bug qu'on ne peut pas corriger par un patch.

L'habitude qui anime ce pilier est une question : et si ? Et si cet enregistrement a des enfants ? Et si deux utilisateurs le suppriment en même temps ? Et si le paiement réussit mais que la confirmation échoue ? C'est dans les cas limites que se cachent les bugs, et l'IA ne les traquera pas pour vous.

Pilier 5 : travailler avec l'IA

La méta-compétence : l'IA est l'outil, vous êtes l'artisan. Cinq disciplines. Tout vérifier — l'IA se trompe de façon fiable sur la sécurité, les cas limites et la performance, et paraît sûre d'elle dans les deux cas. Gérer le contexte — donnez-lui vos règles d'architecture et un ou deux exemples, pas toute votre base de code. Être précis — deux minutes pour écrire un prompt précis en font gagner vingt à corriger un prompt vague, et les prompts structurés sont exactement ce que la méthode PRP systématise. Valider en boucles — vérifications de types, tests, puis tests manuels, avant que quoi que ce soit soit commité. Construire par incréments — d'abord la plus petite version fonctionnelle, puis on enrichit, pour toujours avoir une application qui marche.

Et quand l'IA propose quelque chose qui viole vos règles : résistez. Vous êtes l'architecte ; l'IA est le bâtisseur — cette répartition des rôles est tout le jeu. Battez-vous sur l'architecture, la sécurité et l'intégrité des données. Lâchez prise sur les préférences de nommage et les détails de style. La direction est à vous ; l'exécution est à elle.

Les 5 piliers du logiciel de production en un coup d'œil

Ce cadre n'est pas théorique. C'est ainsi qu'une plateforme de 964 tables de base de données a été construite par une seule personne avec l'IA — et pourquoi le résumé honnête de toute l'approche tient en une phrase : vous apportez la direction, l'IA apporte l'exécution. Le code est gratuit. Les piliers le rendent prêt pour la production. C'est ainsi qu'une plateforme de 2 M€ a été construite pour 3 250 €.

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 →

Questions fréquentes

Dois-je maîtriser les cinq piliers avant de construire quoi que ce soit ?

Non. Commencez à construire tout de suite, mais appliquez le pilier 1 dès le premier prompt — les décisions sur la base de données (colonne d'organisation, row-level security, suppressions logiques) sont celles qui sont brutales à rattraper après coup. Les autres piliers peuvent s'ajouter fonctionnalité par fonctionnalité au fil de l'eau.

N'est-ce pas simplement de l'ingénierie logicielle — pourquoi l'orienter vers l'IA ?

C'est de l'ingénierie logicielle, distillée à ce qui a changé. Avant l'IA, ces principes ne vous servaient à rien sans les années nécessaires pour écrire le code. Aujourd'hui le code est gratuit, donc les principes sont tout le travail — et contrairement à la syntaxe, le jugement ne prend pas vingt ans à appliquer quand quelqu'un vous remet la checklist.

Comment faire suivre les piliers à l'IA sans les répéter à chaque prompt ?

Mettez-les dans un fichier d'instructions permanent que votre outil d'IA lit à chaque session, et référez-vous-y quand vous relisez le résultat. Les corrections les plus fréquentes — chaque table reçoit une colonne d'organisation, chaque composant gère les quatre états, aucune suppression définitive — deviennent des règles écrites une fois. L'article sur les dix principales erreurs de l'IA en production contient le bloc de règles prêt à l'emploi.

Quel pilier les débutants ratent-ils le plus ?

Le pilier 5 — ils font confiance au résultat de l'IA parce qu'il s'exécute. Du code qui tourne est la barre la plus basse qui soit ; la démo cache tout ce que les quatre autres piliers existent pour attraper. Les fondateurs qui réussissent lisent ce que l'IA génère, se demandent « qu'est-ce qui pourrait mal tourner ici ? » et vérifient avant de livrer. Faire confiance, mais vérifier.