Choisir une stack technique pour votre premier SaaS : un guide honnête pour fondateurs

Demandez à dix ingénieurs quelle stack technique utiliser pour votre premier SaaS et vous obtiendrez quinze réponses, dont trois énoncées avec la certitude d'une religion. La plupart de ces réponses sont justes — pour celui qui les donne. Aucune ne parle de vous, de votre marge de manœuvre ni des clients que vous n'avez pas encore signés. Si vous êtes fondateur, face à cette décision, et que vous vous sentez légèrement mal, voici ce que personne ne dit tout haut : la stack compte bien moins qu'on ne vous l'a laissé croire, et les rares façons dont elle compte ne sont pas celles dont on débat en ligne.

J'ai accompagné bon nombre de fondateurs débutants pour passer d'une présentation à un produit que de vraies personnes paient. Presque aucun n'était technique. Presque tous arrivaient en ayant déjà absorbé une quantité effrayante de folklore sur les stacks — qu'ils avaient besoin de microservices, que tel framework était « mort », que se tromper les condamnerait. Et presque à chaque fois, la stack s'est révélée l'une des décisions les moins déterminantes qu'ils aient prises cette année-là. Ce qui tuait les projets, c'était le périmètre, le flou des responsabilités et le fait de construire magnifiquement la mauvaise chose. Jamais le framework.

Voici donc le guide que je donne à ces fondateurs avant d'écrire la moindre ligne de code. Il ne vous dira pas d'utiliser une stack précise, car quiconque le promet sans connaître votre activité vous vend quelque chose. Il vous donnera plutôt une façon de réfléchir — pour que, quoi que vous choisissiez, ou que votre équipe propose, vous puissiez le vérifier sainement, en adulte, au lieu d'acquiescer nerveusement.

Pourquoi cette décision paraît plus difficile qu'elle ne l'est

La question de la stack paraît énorme parce que c'est le premier choix d'apparence irréversible que vous faites, et qu'il est enveloppé dans une langue que vous ne parlez pas. Des mots comme Postgres, React, Kubernetes, serverless sont lancés comme si choisir entre eux revenait à choisir les fondations d'un bâtiment — trompez-vous et tout s'effondre.

Mais un logiciel n'est pas un bâtiment. Il ressemble bien davantage à une cuisine que l'on peut réaménager tout en continuant à cuisiner. Les entreprises qui réussissent réécrivent sans cesse des parties de leur stack ; la version d'un produit qui trouve ses cent premiers clients n'est presque jamais celle qui en sert les cent premiers mille. L'objectif de votre première stack n'est pas de durer éternellement. C'est de vous permettre de construire, modifier et livrer assez vite pour découvrir si quelqu'un veut de cela tout court. C'est une barre tout à fait différente — et bien plus basse — que « parfait pour la décennie à venir ».

Une fois cela accepté, la pression diminue de moitié. Vous n'essayez plus de prédire l'avenir. Vous essayez de faire un pari raisonnable et réversible qui vous mène à un produit qui marche et à des utilisateurs payants. Et les paris raisonnables, c'est quelque chose qu'un fondateur non technique peut tout à fait évaluer.

Ce qu'est réellement une « stack », en clair

Avant de décider quoi que ce soit, il est utile de démystifier le mot. Une stack technique n'est que l'ensemble des outils servant à construire et à faire tourner votre logiciel. Vous pouvez la voir en quatre couches, et vous n'avez besoin d'en comprendre aucune en profondeur — il vous suffit de savoir qu'elles existent.

• Le frontend — ce que les utilisateurs voient et cliquent dans leur navigateur ou leur application. C'est la partie sur laquelle tout le monde vous juge.
• Le backend — la logique et les règles qui tournent sur un serveur : qui peut faire quoi, ce qui se passe quand il le fait, comment l'argent circule.
• La base de données — là où vivent réellement vos informations : utilisateurs, commandes, abonnements, tout ce dont la perte vous anéantirait.
• L'infrastructure — les serveurs et services qui maintiennent tout ce qui précède en ligne, sauvegardé et joignable à 3 heures du matin.

Quand quelqu'un dit « on va utiliser une stack JavaScript moderne » ou « Rails sur Postgres », il décrit des choix répartis sur ces quatre couches. C'est tout. Tout SaaS, du projet annexe à deux jusqu'à l'entreprise cotée, est une version de ces quatre choses empilées. Les diagrammes d'architecture aux grands airs ne sont que cela, dessinés avec davantage de cases.

Ce qui compte vraiment (et ce qui ne compte pas)

C'est là que la plupart des conseils sur les stacks dérapent : ils optimisent des choses qui n'affectent pas vos deux premières années et ignorent celles qui le font. Soyons francs sur les deux listes.

Ce qui compte réellement

Qui peut la construire et la maintenir. Le facteur de loin le plus important n'est pas la technologie — ce sont les gens. La meilleure stack pour vous est celle dans laquelle votre équipe (ou le partenaire que vous engagez) peut réellement travailler, avec aisance, dès aujourd'hui. Une stack « parfaite » que seul un rare spécialiste comprend est un plus mauvais choix qu'une stack ennuyeuse que tout développeur compétent peut reprendre. Le recrutement et la continuité l'emportent à chaque fois sur l'élégance théorique.

À quelle vitesse vous pouvez changer les choses. Au début, vous vous tromperez constamment sur votre produit. Le véritable rôle de la stack est de rendre le changement d'avis bon marché. Des outils matures, bien documentés et entourés de grandes communautés vous font avancer vite, car les réponses à vos problèmes existent déjà. Les outils de pointe font de vous celui qui découvre les bugs.

Si vous pouvez recruter pour cela. Choisissez quelque chose d'obscur et vous liez votre avenir à celui qui l'a construit. Choisissez quelque chose de courant et d'ennuyeux et vous trouverez toujours le prochain développeur, la prochaine agence, la prochaine personne pour reprendre. Ennuyeux est une qualité quand votre activité en dépend.

Ce qui compte bien moins qu'on ne le dit

La performance brute et la « montée en charge ». Vous n'avez pas de problème d'échelle. Vous avez un problème de personne-ne-l'utilise-encore, qui est le problème inverse. Les architectures conçues pour des millions d'utilisateurs vous ralentiront quand vous en aurez onze. Les entreprises célèbres que vous imitez ont d'abord construit la version simple, puis l'ont reconstruite plus tard, financées par le succès. Vous aussi.

Quel framework précis « gagne » cette année. Les frameworks montent et descendent selon un cycle de mode qui n'a presque rien à voir avec leur capacité à bien construire votre SaaS de facturation. N'importe laquelle des options grand public et largement utilisées fera l'affaire. La tendance n'est que du bruit ; choisissez dans le milieu ennuyeux et populaire et passez à autre chose.

Pourquoi la technologie « ennuyeuse » l'emporte le plus souvent

Il existe une sagesse discrète chez les bâtisseurs expérimentés que les nouveaux venus trouvent décevante : la meilleure technologie pour une nouvelle activité est généralement l'ennuyeuse, l'éprouvée, la légèrement démodée. Non parce que les outils neufs sont mauvais, mais parce que chaque choix que vous faites dépense un budget limité de nouveauté — le nombre de choses inconnues, non supportées et surprenantes que votre petite équipe peut gérer à la fois.

Dépensez ce budget sur ce qui rend votre activité spéciale — le produit lui-même, l'intuition que vous seul avez. Ne le dépensez pas pour une base de données dont personne n'a entendu parler, juste pour vous sentir moderne. Une stack ennuyeuse et mature signifie que les problèmes ont déjà été résolus, que la documentation existe, que le recrutement est facile et que l'outil ne disparaîtra pas l'an prochain quand son unique mainteneur se lassera. L'ennuyeux vous permet de placer tout votre enthousiasme là où il rapporte : sur le client.

C'est aussi là que l'IA change un peu la donne — et pas comme le suggère le battage. Les assistants de code à base d'IA sont nettement meilleurs sur les technologies ennuyeuses et populaires, parce qu'ils ont été entraînés sur une décennie de réponses publiques à leur sujet. Choisissez une stack grand public et votre équipe (et vos outils) obtiennent gratuitement une aide plus rapide. Choisissez quelque chose d'exotique et vous êtes seul exactement au moment où vous pouvez le moins vous le permettre.

Une méthode de décision que vous pouvez vraiment utiliser

Assez de principes. Voici une manière concrète d'aboutir à une décision, que vous choisissiez vous-même, briefiez un indépendant ou évaluiez ce qu'une agence propose. Rien de tout cela ne vous demande d'écrire du code — seulement de poser les bonnes questions et de peser les réponses.

1. 1
   Partez de l'équipe, pas de la technique

   Demandez : qui va construire et maintenir cela pendant les deux prochaines années ? Ce qu'ils maîtrisent déjà bien est votre choix par défaut solide. Changer de stack pour courir après une mode bat rarement l'aisance.
2. 2
   Par défaut, le grand public et l'éprouvé

   Choisissez dans le milieu populaire et bien documenté de chaque couche. Si vous ne trouvez pas vite des tutoriels, des offres d'emploi et de grandes communautés pour un outil, voyez-y un avertissement, pas une qualité.
3. 3
   Optimisez pour le changement, pas pour l'échelle

   Privilégiez le choix qui rend la modification de votre produit rapide et bon marché. Vous vous tromperez sans cesse sur le produit — le rôle de la stack est de rendre l'erreur survivable.
4. 4
   Gardez l'architecture aussi simple que possible

   Une base de données. Un backend. Un frontend. Pas de microservices, pas de distribué malin, tant qu'un problème réel et mesuré ne vous y force pas. La simplicité est l'objectif, pas le compromis.
5. 5
   Écrivez pourquoi vous l'avez choisie

   Un paragraphe : qui la construit, ce que vous avez choisi, et ce qui devrait changer pour que vous y reveniez. Cette note vous évite de rejuger la décision à chaque fois que quelqu'un lit un avis tranché.

Si vous ne suivez rien d'autre, suivez les étapes une et quatre. Construisez avec les gens que vous avez, sur l'architecture la plus simple qui fonctionne. Cette combinaison évite en silence les deux modes d'échec qui coulent la plupart des premiers produits SaaS : personne pour le maintenir, et un système trop compliqué pour sa taille.

Questions à poser à qui vous propose une stack

La plupart des fondateurs ne choisissent pas la stack seuls — un développeur, une agence ou un ami CTO en propose une. Vous n'avez pas à vérifier la technologie vous-même. Vous devez poser une poignée de questions et écouter comment on y répond. Des réponses assurées, en langage clair, sont bon signe. Le jargon défensif ne l'est pas.

• « Pourquoi celle-ci, et pas l'ennuyeuse option populaire ? » — une bonne réponse parle de vos besoins précis, pas de ce qui est tendance.
• « Si vous étiez renversé par un bus, avec quelle facilité quelqu'un d'autre pourrait-il reprendre ? » — la réponse révèle à quel point le choix est rare et risqué.
• « Quelle est la version la plus simple de cette architecture qui fonctionne encore ? » — observez s'il va vers la simplicité ou vers la complexité.
• « Avec quelle facilité pourra-t-on recruter le prochain développeur pour cela ? » — des compétences courantes signifient un marché sain ; des compétences exotiques, une dépendance.
• « Que se passe-t-il si l'on doit changer une fonctionnalité centrale dans trois mois ? » — vous voulez entendre que le changement est bon marché, pas redouté.

Pièges courants qui ressemblent à de bonnes idées

Quelques schémas reviennent si souvent qu'il vaut la peine de les nommer, car chacun semble responsable sur le moment et vous coûte cher ensuite.

Construire pour une échelle que vous n'avez pas. L'envie de « bien faire » pousse les fondateurs à concevoir pour des millions d'utilisateurs avant d'en avoir dix. Chaque parcelle de cette anticipation est de la complexité que vous payez maintenant, en temps et en argent, pour résoudre un problème qui n'arrivera peut-être jamais. Construisez pour les cent prochains utilisateurs. Reconcevez quand la croissance l'exige — et que ce soit un heureux problème.

Courir après la nouveauté. Un framework rutilant sorti le mois dernier n'a aucun historique, une documentation maigre et une minuscule communauté. Vous passerez vos nuits à déboguer l'outil au lieu de construire votre produit. Laissez d'autres être les adoptants précoces ; vous avez une activité à livrer.

Sous-traiter au moins-disant, sur ce qu'il préfère. L'offre la plus basse s'accompagne souvent d'une stack obscure que seule cette équipe connaît. Le jour où vous vous séparez, votre produit devient une île que personne d'autre ne peut atteindre. Bon marché au départ, ruineux ensuite. Exigez une technologie grand public et recrutable même quand vous sous-traitez — surtout quand vous sous-traitez.

Quand il est vraiment temps de revoir votre stack

Rien de tout cela ne signifie « ne jamais changer ». Cela signifie changer pour de vraies raisons, mesurées, pas imaginées. Vous saurez qu'il est vraiment temps de faire évoluer votre stack quand des signaux concrets apparaîtront — pas quand un article de blog vous angoisse.

Remarquez le schéma : les vraies raisons concernent une douleur mesurée dans votre activité réelle. Les fausses concernent la mode, la comparaison et l'agitation. Quand un vrai signal apparaît, vous changez une pièce à la fois — pas toute la stack dans une réécriture héroïque qui bloque tout pendant six mois. Évolution, pas révolution.

Questions fréquentes