L’empilement SaaS a atteint son point de bascule. Selon le rapport BetterCloud State of SaaSOps 2024, l’entreprise moyenne utilise désormais 106 applications SaaS. Et près de la moitié des licences ne sont pas utilisées. Cette inflation a un coût réel : environ 5 600 dollars par employé et par an.

Mais quelque chose a changé en parallèle. L’IA générative a rendu le code accessible à des gens qui n’avaient jamais ouvert un terminal. Et cette accessibilité change l’équation classique build vs buy.

Pour rendre l’idée concrète : j’ai construit mon propre outil de gestion de projet pour remplacer Asana. Trois semaines de travail, zéro formation d’ingé, et un outil qui colle exactement à mon workflow solo. Voici la démo, puis l’analyse de fond.

Project OS en vidéo : l’outil que j’ai construit

Trois minutes de démo screen record pour comprendre ce qu’on peut livrer en quelques semaines quand on s’autorise à coder soi-même avec une IA.

La vidéo est hébergée dans mon post LinkedIn original. Tu peux la regarder directement ci-dessous, ou ouvrir le post complet avec les commentaires.

→ Voir le post complet sur LinkedIn

Pourquoi cette question revient en 2026

Pendant quinze ans, la logique du buy a écrasé la logique du build dans les équipes growth et ops. Trois raisons à ça. Le code coûtait cher. Les délais de livraison étaient longs. Les outils SaaS prêts à l’emploi couvraient 80% des besoins pour 30 euros par mois.

Trois choses ont basculé en deux ans.

Le code est devenu accessible. Avec Claude Code ou Cursor, un non-développeur capable de spécifier précisément un besoin peut livrer un outil fonctionnel en quelques jours. Pas un prototype, un vrai produit qu’il utilise au quotidien.

Les infrastructures sont devenues gratuites. Le free tier de Supabase et de Vercel suffit pour 99% des cas d’usage solo. Tu peux faire tourner un SaaS personnel sans payer un centime d’hébergement.

Le SaaS empilé est devenu cher. 106 apps en moyenne, 49% de licences inutilisées, 5 600 dollars par employé. Le calcul change quand chaque outil custom remplace une ligne SaaS.

Project OS : le cas concret

J’ai utilisé Asana pendant deux ans. Bon outil. Mais surcalibré pour mon usage solo de GTM Engineer freelance. Trop de fonctions inutiles, friction sur les workflows que je voulais, et 25 euros par mois pour 10% des fonctionnalités utilisées.

J’ai construit Project OS en trois semaines avec Claude Code. Une stack simple : Next.js sur Vercel pour le frontend, Supabase pour la base de données et l’authentification Google OAuth, une UI minimaliste calibrée pour ma façon de travailler.

Le résultat : un outil qui fait exactement ce dont j’ai besoin, ni plus ni moins. Zéro coût mensuel (free tier partout). Aucune limite de personnalisation. Et surtout, un outil qui évolue à mon rythme : quand je veux ajouter une fonction, je l’ajoute dans la semaine.

C’est ce que la vidéo plus haut montre concrètement. Pas un cas isolé : j’ai construit Sihati.ma, Veille Alimentaire Maroc, et un système de pointage pour livreurs avec la même approche.

Build vs buy : la grille de décision en 2026

Construire soi-même n’est pas systématiquement la bonne décision. Voici la grille que j’applique pour trancher.

La règle générale que j’applique : quand un outil SaaS coûte 30 euros par mois et ne couvre que 30% de mon besoin, je passe en build. Quand un outil SaaS couvre 80% du besoin pour le même prix, je continue d’acheter.

Trois conditions pour que le build marche

Le code n’est plus un coût fixe. C’est devenu un levier accessible à qui sait spécifier précisément un besoin.