Lancer vite, puis tenir : SaaS, IA, et le moment de maîtriser sa stack

Aujourd'hui, on lance un produit en un week-end. Le front et les fonctions sur Vercel, la base de données et l'authentification sur Supabase, les tâches asynchrones sur Trigger.dev, un service pour les e-mails, un autre pour les fichiers, un troisième pour les logs. Et l'IA écrit le code qui relie le tout. C'est formidable, et pour un prototype c'est souvent le bon choix : rien à installer, rien à surveiller, des offres gratuites généreuses.

Mais un prototype n'est pas un produit. Le jour où le projet devient sérieux, avec des clients qui paient, des données qui comptent et une équipe qui grandit, la question change. Ce n'est plus « comment lancer vite ? », c'est « comment tenir ? ».

Ce que coûte la dispersion

Les données sont partout. Chaque fournisseur garde une part des données de vos utilisateurs : la base, bien sûr, mais aussi les e-mails envoyés, les fichiers, les journaux, le contenu des tâches. Autant de contrats de sous-traitance, de régions, de clés d'accès dans les variables d'environnement, et de portes d'entrée en cas de fuite. Pour une entreprise suisse ou européenne, chacun doit tenir face à la nLPD et au RGPD. Plus il y a de fournisseurs, plus il suffit d'un seul pour créer un problème.

La latence s'additionne. Les fonctions tournent dans une région, la base dans une autre, souvent parce que c'était le réglage par défaut. Dans un même réseau, un aller-retour vers Postgres prend moins d'une milliseconde ; d'un continent à l'autre, près de cent. Une page qui enchaîne six requêtes passe ainsi de quelques millisecondes à une demi-seconde, sans qu'une seule ligne de code ait changé.

La facture suit l'usage, et les marges s'empilent. Les offres gratuites sont généreuses, puis viennent les paliers : par utilisateur actif, par exécution, par gigaoctet transféré, par siège. Chaque fournisseur prend sa marge sur des machines qu'il loue souvent lui-même à un grand cloud. Une stack que l'on fait tourner soi-même démarre plus cher, car il faut des serveurs et surtout le savoir-faire pour les exploiter. Mais elle grandit lentement : une machine de plus coûte peu.

Partir coûte de plus en plus cher. Le verrou n'est presque jamais la base : Supabase, c'est du Postgres, et le projet est open source, tout comme Trigger.dev, que l'on peut héberger soi-même. Le verrou est dans la colle : les fonctionnalités propres à chaque plateforme, les règles d'accès écrites dans leur format, les habitudes de l'équipe. Plus on attend, plus il y en a.

Le piège. Basculer trop tôt, c'est passer ses semaines sur l'infrastructure au lieu du produit. Basculer trop tard, c'est payer deux fois : la facture, puis une migration sous pression. Le bon moment se prépare dès le premier jour, en choisissant des briques ouvertes : PostgreSQL, Docker, OpenTelemetry, Temporal.

Maîtriser sa stack, c'est un métier

Maîtriser sa stack ne veut pas dire tout faire soi-même. Une base Postgres managée chez son hébergeur, dans la même région que l'application, est souvent le bon compromis, et l'envoi d'e-mails reste un service externe. Cela veut dire savoir ce qui tourne, où, et pourquoi.

C'est le choix de Filetable. L'application, ses workers, Temporal (auto-hébergé, puisqu'il est open source) et l'observabilité tournent dans un même cluster Kubernetes, en Suisse, à côté des données. Mais il faut quelqu'un qui sache le faire : les mises à jour, les sauvegardes et leur restauration, les déploiements sans coupure, les files de priorité, la requête lente qu'il faut comprendre avant de deviner. Au bout d'un moment, une stack se gère par des professionnels.

Et l'IA dans tout ça ?

L'IA a appris sur des millions de projets publics : des tutoriels, des démos, des modèles de départ, des projets d'un week-end. Très peu ont connu une deuxième version, une migration de données ou une nuit d'astreinte. Elle excelle donc à produire ce qui impressionne en surface : un jeu en 3D avec WebGL, une landing page splendide, une démo qui marche du premier coup. Ce qui fait tenir un produit est sous la ligne de flottaison.

Surtout, l'IA va toujours au plus vite. Pour elle, une tâche est finie quand la vérification passe au vert. Si un test échoue, le plus court est de modifier le test ; si un type résiste, de le forcer ; si une fonction existe déjà ailleurs, d'en écrire une deuxième. Ce n'est pas de la malveillance : c'est ce que « fini » veut dire de son point de vue. Elle ne sait pas non plus où va le projet, quels volumes il aura dans un an, ni ce que la version en ligne supportera pendant un déploiement.

Il faut donc un ingénieur senior à côté : pour challenger ce qu'elle propose, comprendre où va le projet, et s'assurer qu'on n'est pas en train de construire une énième app jetable, belle en démo et fragile dès le premier vrai client.

Comment je travaille avec l'IA

Je l'utilise au maximum : le code, les tests, les migrations, la documentation, les revues. Elle me fait gagner des semaines. Mais jamais en pilote automatique. Chaque projet a ses règles écrites, que l'IA lit avant d'écrire une ligne ; des garde-fous automatiques refusent ce qu'on a déjà vu passer ; et rien ne part en production sans relecture. Chaque erreur repérée devient une règle de plus.

Les signaux qu'il est temps de reprendre la main

• La facture grimpe plus vite que le nombre d'utilisateurs.
• Une page fait plusieurs allers-retours vers une base située dans une autre région.
• Plus personne ne sait dire où sont toutes les données, ni qui y a accès.
• Les fonctionnalités se plient aux limites d'un fournisseur : délais, quotas, tailles maximales.
• Le code a été écrit vite, avec l'IA ou non, et plus personne n'ose y toucher.

Ce que j'en retiens

• Lancer vite avec des SaaS, oui, mais avec des briques ouvertes, pour que partir reste possible.
• Le point de bascule existe, et il arrive souvent plus tôt qu'on ne le croit. Le franchir demande un savoir-faire : exploiter une stack, c'est un métier.
• L'IA au maximum, mais comme un outil. Elle n'est pas autonome, et elle ira toujours au plus vite. Il faut un ingénieur pour la cadrer, la relire, et décider de ce qui part en production.