Architecture logicielle d'une startup : comment savoir si elle est bonne

Une architecture logicielle de startup n'est pas bonne dans l'absolu. Elle est bonne si elle rend facile ce que le produit doit devenir dans les six prochains mois, et si elle laisse ouvert ce qui n'est pas encore décidé. Pour le savoir, il faut d'abord savoir où va le produit. C'est une question produit avant d'être une question technique.

Excellent, et quand même dépassé

À notre Product Guild, on a étudié le cas BlackBerry. Une phrase de la session m'est restée : ils n'étaient pas en retard, ils étaient excellents.

En 2007, BlackBerry avait le meilleur clavier du marché et une sécurité que les gouvernements s'arrachaient. Rien n'était mal fait. Puis le jeu a changé de question, et tout ce qui était excellent répondait à l'ancienne.

Une codebase peut vivre exactement la même chose à petite échelle. Le code est propre et les tests passent. Et la prochaine décision produit tombe pile à l'endroit que l'architecture avait figé.

Ce que l'IA change

Avec Claude Code, du code propre ne coûte presque plus rien. Demandez un module bien découpé et testé : vous l'aurez en quelques minutes. Il aura l'air d'une bonne architecture.

Le problème, c'est que l'IA optimise pour la demande qu'elle a sous les yeux. Elle ne connaît pas votre roadmap, sauf si quelqu'un la lui écrit. Elle ne sait pas que vos premiers clients payants seront des équipes et pas des individus. Elle ne sait pas que votre marché va vous pousser vers les abonnements. Elle fait donc des choix raisonnables pour un produit qui n'est pas le vôtre.

C'est pour ça que « est-ce que le code est bon ? » est devenue une question facile. La question difficile, c'est : bon pour quoi ?

La même architecture, bonne ou mauvaise selon le produit

Prenons des cas qu'on croise souvent dans les repos early-stage.

Le compte appartient à l'utilisateur. Chaque ressource porte un userId, chaque requête filtre dessus. Pour une app grand public, c'est parfait. Pour un produit qui vendra bientôt à des équipes, c'est le mauvais socle : il faudra introduire une organisation, déplacer la propriété des données, réécrire les permissions. Si la vente aux équipes est dans le plan, un organizationId dès le départ coûte une heure. Six mois plus tard, c'est une migration qui touche toutes les tables.

Tout se fait dans la requête. L'utilisateur clique, l'API appelle le modèle d'IA, attend, répond. Simple, lisible, très bien tant que l'appel prend deux secondes. Si le produit doit traiter des documents longs ou enchaîner plusieurs appels, la même structure devient des timeouts. Une file de tâches serait de la sur-ingénierie pour le premier produit et une nécessité pour le second.

Un seul modèle « Produit ». Une table, des colonnes plates. Si vous vendez des objets uniques, c'est la bonne réponse. Si les variantes (tailles ou formules) arrivent au trimestre prochain, chaque écran construit sur cette table sera à reprendre.

Dans aucun de ces cas le code n'est mal écrit. Il répond juste à une question que le produit ne pose pas, ou plus.

Pourquoi nos ingénieurs étudient le produit

Le vendredi matin, nos ingénieurs n'écrivent pas de code. Ils étudient le produit, sur du matériel YC ou sur des cas comme celui de BlackBerry.

Reviewer le code d'un fondateur sans comprendre où va son produit, c'est corriger l'orthographe d'une phrase sans savoir ce qu'elle veut dire. Un ingénieur qui comprend la courbe d'une startup chiffre autrement et review autrement. Surtout, il dit non autrement. Il refuse une abstraction élégante parce qu'elle protège un futur qui n'arrivera pas, et il en demande une plus lourde là où la roadmap va frapper.

Concrètement, ça se traduit dans la méthode. Le planning de sprint commence par ce que le produit doit devenir, pas par la liste des tickets. Les surfaces qui portent ces décisions sont inscrites dans l'Expandable Core, et toute PR qui les touche passe en revue d'architecture. Chaque décision importante produit un ADR qui écrit l'hypothèse produit derrière le choix technique. Le jour où l'hypothèse change, on sait quel code relire.

Vérifier la vôtre en trente minutes

1. Écrivez en une phrase ce que le produit doit savoir faire dans six mois et qu'il ne sait pas faire aujourd'hui.
2. Ouvrez le repo et cherchez où cette capacité devrait vivre. Le modèle de données le permet-il, ou faut-il le casser ?
3. Relisez vos décisions d'architecture, même informelles. Est-ce qu'au moins une mentionne une hypothèse produit, ou sont-elles toutes justifiées par « c'est plus propre » ?

Si la réponse à la deuxième question est « il faut tout casser », ce n'est pas un drame. C'est une information, et elle coûte beaucoup moins cher aujourd'hui qu'à la feature #30.

---

Le Bunker Test, gratuit. Vous nous donnez un accès en lecture seule à votre repo. On revient sous 5 jours ouvrés avec un score de Solidité et de Structure sur 100, vos 3 risques principaux et un correctif que vous pouvez livrer le jour même. Walkthrough de 15 minutes inclus, aucun engagement.

Demander votre Bunker Test →