Qu’est-ce qu’une tech stack ? Le guide du fondateur non technique

Le guide du fondateur non technique sur la tech stack : pas comment en choisir une, mais comment distinguer une bonne décision de stack d’une mauvaise, quels choix coûtent cher à revenir en arrière, et quelles questions poser à celui qui construit votre produit.

La première fois que la plupart des fondateurs entendent les mots “tech stack” prononcés avec du poids, c’est dans une salle qu’ils n’arrivent pas vraiment à lire. Pour Priya, c’était lors d’un call de due diligence en Série A. L’associé en face, sympathique jusqu’à cet instant, a demandé quelle était sa stack. Elle connaissait son produit. Elle savait ses chiffres par cœur. Mais elle ignorait si “Rails et Postgres sur AWS” était la bonne réponse ou un aveu, et la demi-seconde de silence a indiqué à toute la salle laquelle des deux c’était.

Une tech stack est l’ensemble des technologies sur lesquelles votre logiciel est construit : les langages de programmation, les frameworks, la base de données et l’infrastructure qui, empilés, font tourner votre produit. Voilà toute la définition. Une question du type “qu’est-ce qu’une tech stack” ne veut presque jamais plus que ça, et les schémas en couches qui remplissent les résultats de recherche la font paraître plus mystérieuse qu’elle ne l’est. La vraie question difficile, celle à laquelle personne qui écrit sur la tech stack ne semble répondre, est celle que Priya avait vraiment : vous n’avez pas choisi votre stack, vous ne pouvez pas lire le code qui tourne dessus, alors comment êtes-vous censé savoir si la vôtre vaut quelque chose ?

Voici le guide qu’on aurait aimé que cette fondatrice ait avant le call. Il ne va pas vous apprendre à choisir une stack. En tant que fondateur non technique, vous ne devriez pas en choisir une, de la même manière que vous ne devriez pas écrire le SQL. Il va vous apprendre à évaluer celle qu’on vous a remise, à savoir quelles parties coûtent cher à rater et à poser les quatre questions qui séparent une stack choisie pour votre entreprise d’une stack choisie pour le CV de quelqu’un.

Ce qu’est une tech stack, en clair

Imaginez votre produit comme un bâtiment. La tech stack, c’est tout ce qui est structurel plus tout ce avec quoi vous l’avez meublé. On la décrit en général en couches, et les couches correspondent bien à des choses que vous comprenez déjà en tant qu’opérateur.

Le frontend est ce que vos utilisateurs voient et touchent : les écrans, les boutons, l’appli sur le téléphone. Quand quelqu’un dit “React” ou “Swift”, il nomme les outils utilisés pour construire cette surface. Le backend est la partie que l’utilisateur ne voit jamais : la logique qui décide ce qui se passe quand il clique, qui a le droit de faire quoi, comment une commande devient un paiement. La base de données est l’endroit où est stocké tout ce que votre entreprise sait : vos clients, leurs transactions, leur historique. L’infrastructure est le sol sur lequel tout repose : les serveurs, le plus souvent loués à Amazon, Google ou Microsoft, qui gardent le tout en ligne à 3 heures du matin.

Un exemple concret, parce que “qu’est-ce qu’une tech stack” se répond mieux avec un. Un produit SaaS typique en phase d’amorçage peut faire tourner React sur le frontend, un backend en Node ou Ruby, une base Postgres, hébergé sur AWS, avec Stripe branché pour les paiements et quelques services de plus vissés pour l’e-mail et l’analytique. Cette phrase est une tech stack complète. Si votre développeur ne peut pas décrire la vôtre en une phrase aussi simple, ça mérite qu’on s’y attarde, et on y reviendra.

Ce qu’il faut retenir : chaque couche est une décision d’entreprise habillée en technique. La base de données n’est pas seulement l’endroit où vivent les données ; c’est la vitesse à laquelle vous répondez à la question d’un client et la douleur que représentera le déplacement de ces données dans trois ans. L’infrastructure n’est pas seulement des serveurs ; c’est une facture mensuelle qui grandit avec votre croissance. Rien de tout cela n’exige que vous codiez. Cela exige que vous traduisiez.

Vous ne choisirez pas votre stack. Vous devez quand même savoir la lire.

Il y a un piège des deux côtés. Un fondateur traite la stack comme une affaire qui ne le regarde pas, la délègue entièrement à un développeur et découvre deux ans plus tard qu’un seul prestataire est la seule personne vivante à comprendre comment l’entreprise fonctionne. L’autre fondateur lit trois articles de blog, se forge des opinions sur le fait que l’équipe devrait utiliser MongoDB et commence à passer par-dessus les gens qu’il a embauchés précisément pour prendre cette décision. Les deux ont tort. Le travail n’est ni de choisir la stack ni de s’en remettre entièrement à d’autres. Le travail est de savoir la lire.

La lire signifie trois choses. Vous savez décrire votre stack en langage simple à un investisseur ou à une nouvelle recrue. Vous savez quels choix en son sein sont réversibles et lesquels sont quasi permanents. Et vous repérez quand une décision technique est prise pour une raison technique et quand elle l’est pour une raison personnelle. Cette dernière compétence est tout le jeu, et la plupart des fondateurs ne la développent jamais parce que personne ne leur dit que c’est une chose qu’ils ont le droit d’évaluer.

C’est aussi ici que la stack rejoint une décision que vous avez peut-être déjà affrontée : construire quelque chose sur mesure ou acheter une solution sur étagère. Toute réponse “construire” vous engage dans une stack. Savoir lire cette stack, c’est la différence entre une décision de construire que vous maîtrisez et une qui vous maîtrise.

Les décisions bon marché à changer, et celles qui ne le sont pas

Tous les choix de votre stack ne pèsent pas le même poids, et la chose la plus utile qu’un fondateur non technique puisse apprendre, c’est de distinguer les lourds des légers.

Certaines décisions sont réversibles. L’outil d’analytique, le service qui envoie votre e-mail transactionnel, la bibliothèque qui dessine vos graphiques : on peut les remplacer en une après-midi, ou au moins en un sprint, sans que personne n’en perde le sommeil. Si l’équipe en a choisi un et qu’il se révèle mauvais, le coût de l’erreur est faible. Vous pouvez laisser ces décisions se prendre vite et se changer plus tard.

D’autres décisions sont porteuses, du genre qui soutient le toit. Votre langage de programmation principal, votre base de données, la forme de base de l’organisation du système : cela se coule comme des fondations. Changer plus tard n’est pas un remplacement ; c’est une reconstruction. Une entreprise qui décide, à trente ingénieurs, de quitter son langage d’origine se prépare à un projet qui se compte en trimestres et brûle de l’argent réel, le genre de reconstruction dont personne ne voulait. La question de plateforme, partir en natif ou en cross-platform sur le mobile, appartient aussi à cette catégorie plus lourde : réversible en théorie, coûteuse en pratique.

Vous n’avez pas besoin de savoir quelle base de données est la meilleure. Vous avez besoin de savoir que la base de données est une décision qui soutient le toit et que le fournisseur d’e-mail ne l’est pas, pour savoir où ralentir et poser des questions et où laisser l’équipe filer. Quand un développeur dit “ça, on le changera plus tard”, votre seul travail est de poser une question : est-ce vraiment une décision modifiable plus tard, ou me dites-vous ça parce qu’elle est déjà prise ? Les bons bâtisseurs vous diront la vérité. La distinction entre réversible et porteur est la version d’ingénierie des structures du fondateur. Vous ne coulez pas le béton. Vous vous assurez que quelqu’un a vérifié quels murs soutiennent le toit.

La lecture en quatre questions : comment évaluer une stack que vous ne codez pas

Voici le script. Quand quelqu’un propose une stack, ou quand vous en héritez d’une et voulez savoir sur quoi vous tenez, posez ces quatre questions et écoutez moins les réponses que la façon dont elles sont données.

1. « Pourquoi ça et pas le choix évident et ennuyeux ? » Il existe presque toujours un défaut pour chaque tâche, l’option que la plupart des équipes prennent parce qu’elle est bien comprise. Si votre développeur a choisi le défaut, il devrait pouvoir le dire franchement. S’il a choisi autre chose, il devrait y avoir une raison liée à votre entreprise, pas au fait que la technologie soit intéressante. « On a pris Postgres parce que c’est le bon choix ennuyeux » est une excellente réponse. « On a pris une base de graphes parce qu’elle colle mieux à la forme réelle de ces données » est une excellente réponse. « On l’a prise parce que je voulais l’apprendre » est la réponse que vous guettez, et elle devrait vous mettre en alerte.

2. « Combien de personnes peuvent travailler là-dessus si vous vous faites renverser par un bus ? » Adoucissez la question si vous voulez, mais elle est réelle. Une stack bâtie sur une technologie populaire et très répandue veut dire que vous recrutez vos trois prochains développeurs dans un vivier de milliers. Une stack bâtie sur quelque chose d’exotique veut dire que votre vivier de talents est un groupe de discussion. Vous n’achetez pas seulement du logiciel quand vous validez une stack ; vous achetez votre capacité future à la doter en personnel.

3. « Qu’arrive-t-il à cette facture à mesure qu’on grandit ? » Certaines stacks sont bon marché à dix utilisateurs et brutales à dix mille. Demandez à l’équipe de vous expliquer ce que coûte l’infrastructure aujourd’hui et à quoi elle ressemble à dix fois votre charge actuelle. Vous ne pourrez pas vérifier le calcul, mais vous saurez s’ils y ont pensé. Une équipe qui n’a jamais modélisé cela est une équipe qui vous surprendra avec une facture.

4. « Montrez-moi la partie dont vous êtes le moins fier. » La réponse honnête à cela vous en dit plus que n’importe quel beau schéma d’architecture. Tout système réel a un coin tenu par du ruban adhésif, un raccourci pris sous la pression du délai, un morceau connu de dette technique. Une équipe qui peut pointer la sienne et expliquer le compromis est une équipe honnête avec vous. Une équipe qui affirme que tout est propre ment ou ne sait pas, et vous ne pouvez pas distinguer lequel des deux, ce qui est un problème en soi.

Vous remarquerez qu’aucune de ces quatre questions n’exige que vous compreniez la réponse techniquement. Elles exigent que vous lisiez la personne qui répond. C’est la vraie compétence, et les fondateurs venus de la finance et du conseil l’ont déjà. Vous avez déjà évalué des gens que vous ne pouviez pas surpasser sur le plan technique. C’est le même muscle. C’est aussi le même muscle que vous mobilisez quand vous allez choisir une entreprise de développement logiciel au départ : vous jugez le jugement, pas le code.

Les signaux d’alerte : quand la stack a été choisie pour l’ingénieur, pas pour l’entreprise

Il existe un mode d’échec en logiciel qui porte un nom chez les développeurs : le développement piloté par le CV. C’est quand la technologie est choisie non parce qu’elle est juste pour le problème, mais parce qu’elle fait bien sur le CV de la personne ou parce que c’est le framework dont tout le monde parlait à la dernière conférence. C’est l’une des erreurs les plus courantes et les plus coûteuses du logiciel en phase d’amorçage, et un fondateur non technique y est particulièrement vulnérable parce qu’il ne peut pas la voir se produire.

Les signes, pourtant, se laissent connaître. Méfiez-vous quand la stack est pleine de technologies très récentes, où l’argument en leur faveur est l’enthousiasme et non l’adéquation. Méfiez-vous quand deux parties du système n’utilisent pas la même approche, signe que celui qui l’a construite collectionnait des outils au lieu de résoudre un problème. Méfiez-vous surtout quand vous demandez pourquoi quelque chose a été choisi et que la réponse glisse vers à quel point c’est moderne, à quel point c’est à la pointe, à quel point c’est l’avenir. L’avenir n’est pas une raison. L’adéquation à votre vrai problème est une raison.

Le problème de fond, c’est qu’une stack choisie par mode vous transfère le risque, en silence. L’ingénieur garde l’apprentissage et la ligne sur son CV. Vous gardez un système difficile à recruter pour lui, difficile à maintenir et bâti sur quelque chose qui peut être abandonné dans deux ans. Nous avons vu des fondateurs hériter de bases de code écrites dans des frameworks à la mode pendant dix-huit mois et sans support au moment où l’entreprise a eu besoin de passer à l’échelle. La facture de cette mode tombe sur le fondateur, jamais sur celui qui a choisi. Une stack devrait être ennuyeuse comme une bonne plomberie est ennuyeuse. Vous voulez qu’elle fonctionne, pas qu’elle impressionne vos amis.

Pourquoi l’ennuyeux l’emporte souvent

Les tech stacks les plus populaires le sont pour une raison peu glamour : assez de gens les utilisent pour que les problèmes soient résolus, la documentation épaisse et le vivier de talents profond. Quand vous bâtissez sur une technologie largement adoptée, vous vous tenez sur le débogage accumulé de millions d’autres développeurs. Quand vous bâtissez sur la chose exotique, vous la déboguez vous-même, seul, au pire moment possible.

Vous n’êtes pas obligé de le croire sur parole. Le sondage des développeurs de Stack Overflow demande chaque année à des dizaines de milliers de développeurs en activité ce qu’ils utilisent vraiment, et les réponses sont une carte exploitable de ce qui est bien supporté et facile à recruter. Les choix ennuyeux et dominants de cette liste sont dominants parce qu’ils continuent de fonctionner. Pour une entreprise en phase d’amorçage, « populaire et bien compris » l’emporte sur « nouveau et impressionnant » presque à chaque fois, parce que votre contrainte est rarement la technologie elle-même. Votre contrainte est votre capacité à recruter des gens pour y travailler, à la réparer vite quand elle casse et à ne pas être l’otage de la seule personne qui comprend la partie astucieuse.

C’est le même instinct que Pixel Breeders apporte à chaque projet. Sur mesure ne veut pas dire exotique. Ça veut dire un système façonné pour votre entreprise, fait pour servir et fait pour passer à l’échelle, sur une fondation où d’autres pourront se tenir après vous. Le soin est dans l’ajustement, pas dans la nouveauté des pièces. Une stack pour laquelle vous pouvez recruter, que vous pouvez expliquer en une phrase et transmettre à la personne suivante sans cérémonie, n’est pas un compromis. C’est l’objectif.

Priya, pour mémoire, avait une bonne stack. Rails et Postgres sur AWS est le bon choix ennuyeux pour une entreprise à son stade, et la question de l’associé n’était pas un piège ; c’était un test exactement de cette lucidité qu’elle a maintenant construite. La prochaine fois qu’on lui demandera quelle est sa stack, la demi-seconde de silence ne viendra pas. Non parce qu’elle a appris à coder. Parce qu’elle a appris à lire.

Questions fréquentes

Qu’est-ce qu’une tech stack ?
Une tech stack est l’ensemble des technologies sur lesquelles tourne votre logiciel : les langages de programmation, les frameworks, la base de données et l’infrastructure qui se combinent pour faire fonctionner le produit. Un exemple courant : React sur le frontend, un langage de backend comme Ruby ou Node, une base Postgres, hébergé sur AWS. En tant que fondateur, vous n’avez pas à la choisir, mais vous devriez pouvoir décrire la vôtre en une phrase simple.

Qu’est-ce qu’un exemple de tech stack ?
Une stack SaaS typique en phase d’amorçage : React pour l’interface, un backend en Node.js ou Ruby on Rails pour la logique, PostgreSQL comme base de données, hébergé sur Amazon Web Services, avec Stripe qui gère les paiements. Chaque pièce fait un travail, et ensemble elles forment la tech stack de l’entreprise. Si votre équipe ne peut pas résumer la sienne aussi simplement, demandez pourquoi.

Quelle est la tech stack la plus populaire ?
Il n’y a pas de vainqueur unique, mais les pièces les plus utilisées se regroupent autour de quelques options bien supportées : JavaScript et TypeScript sur le frontend, des langages comme Python, Ruby, Node ou Java sur le backend, PostgreSQL ou MySQL pour les données, et AWS, Google Cloud ou Azure pour l’hébergement. La popularité compte parce qu’elle signifie plus de documentation, plus de problèmes résolus et un vivier plus profond de gens à recruter.

Quelle est une bonne tech stack pour une startup ?
Une bonne stack de startup est ennuyeuse exprès : bâtie sur une technologie populaire et bien documentée pour laquelle vous pouvez recruter, sans choix exotiques sauf raison d’affaires claire. La meilleure stack pour une entreprise en phase d’amorçage est celle qui vous laisse livrer, changer pas cher là où c’est possible et recruter facilement, pas la plus récente ou la plus impressionnante.

Un fondateur non technique doit-il choisir la tech stack ?
Non. Choisir la stack est le travail de votre développeur ou partenaire technique. Votre travail est d’évaluer le choix : savoir quelles décisions coûtent cher à revenir en arrière, demander pourquoi chaque grande pièce a été choisie et vous assurer que la stack a été sélectionnée pour votre entreprise et non pour le CV de quelqu’un. Vous jugez le jugement, pas le code.

Comment savoir si ma tech stack est dépassée ?
Les signaux sont pratiques, pas techniques : il devient difficile de recruter des gens qui connaissent la technologie, l’équipe évite de toucher à certaines parties, le bâtisseur d’origine est la seule personne à la comprendre, ou la technologie de base n’est plus activement supportée. Une stack vieillissante échoue rarement bruyamment. Elle devient juste plus lente et plus chère à changer, jusqu’à ce que la reconstruction devienne inévitable.