La semaine dernière, j'ai vu un développeur junior de notre équipe créer une application CRUD fonctionnelle avec authentification, migration de base de données et une interface utilisateur à peu près décente en 90 minutes. Avec Copilot. En partant de zéro.
Il y a cinq ans, cette même tâche aurait pris une semaine. Peut-être deux si l'on compte les configurations de déploiement et les flux OAuth. Et ce changement, cette compression du temps de construction de jours en heures, est en train de démanteler tranquillement l'une des plus vieilles questions en matière de logiciels : devons-nous construire ou acheter ?
L'ancien cadre est mort
Pendant des décennies, la question "construire ou acheter" était un calcul de coût. On évaluait le nombre de mois-développeur nécessaires à la création d'un produit, on le multipliait par le salaire, on ajoutait une marge pour la maintenance et on le comparait au prix de la licence annuelle d'un produit SaaS qui faisait à peu près la même chose. Si le SaaS était moins cher, vous l'achetiez. Si vos besoins sont suffisamment étranges, vous construisez.
Ce cadre supposait que la construction était coûteuse. Et c'était le cas. Mais [selon les données Octoverse 2025 de GitHub] (https://github.blog/ai-and-ml/generative-ai/how-ai-is-reshaping-developer-choice-and-octoverse-data-proves-it/), le développement assisté par l'IA produit désormais une augmentation de 20 à 30 % du débit. Quatre-vingt pour cent des nouveaux développeurs sur GitHub utilisent Copilot au cours de leur première semaine. Plus de 1,1 million de dépôts publics intègrent déjà les SDK LLM. La construction est devenue nettement moins chère, presque du jour au lendemain.
La question n'est donc plus vraiment "construire ou acheter". Il s'agit plutôt de savoir ce que vous payez réellement lorsque vous achetez un SaaS.
Le nouveau calcul
Voici ce que je pense que la plupart des fondateurs de SaaS (moi y compris, honnêtement) ne veulent pas entendre : si toute votre proposition de valeur est " nous vous avons évité de le construire ", vous êtes dans le pétrin. Parce que ce fossé vient de devenir beaucoup moins profond.
Lorsqu'une équipe peut prototyper un outil interne fonctionnel en une journée, la barre de ce qui justifie un abonnement mensuel s'élève considérablement. Vous ne devez pas seulement être meilleur que ce qu'ils pourraient construire. Vous devez être meilleur que ce qu'ils pourraient construire avec l'aide de l'IA.
[Gartner a prédit en avril 2026] (https://www.gartner.com/en/newsroom/press-releases/2026-04-02-gartner-expects-most-enterprises-to-abandon-assistive-ai-for-outcome-focused-workflow-by-2028) que d'ici 2028, plus de la moitié des entreprises cesseront de payer pour l'intelligence d'assistance et privilégieront les plateformes qui s'engagent à fournir des résultats en matière de flux de travail. Plus grave encore : d'ici à 2030, les éditeurs de logiciels qui superposent l'IA aux applications existantes au lieu de les repenser pour une exécution agentique devront faire face à une compression de leurs marges pouvant aller jusqu'à 80 %.
Quatre-vingts pour cent. Il ne s'agit pas d'une erreur d'arrondi.
Alors, qu'est-ce qui survit vraiment ?
J'ai beaucoup réfléchi à cette question, en partie parce que nous construisons Rasepi et que je dois être honnête avec moi-même quant à notre valeur. Et je pense que la réponse se résume à trois choses qui sont vraiment difficiles à reproduire en un week-end de codage, quelle que soit la qualité de votre assistant IA.
**N'importe qui peut créer un éditeur de texte. Construire un système de traduction qui suit les changements de contenu au niveau du paragraphe, détecte les traductions périmées grâce au hachage du contenu et gère l'adaptation structurelle entre les langues ? Cela nécessite des années de connaissances dans le domaine, intégrées dans l'architecture. L'IA peut vous aider à écrire le code plus rapidement, mais elle ne peut pas vous dire quoi construire.
Il faut toujours que quelqu'un l'exécute et l'entretienne. Ce qu'il y a de bien avec la construction : c'est amusant. La maintenance ? Pas amusant du tout. Gérer les cas limites dans les systèmes de permission multi-locataires, suivre les bizarreries des navigateurs, gérer les migrations de bases de données à travers les versions, patcher les CVE à 2 heures du matin, gérer ce bug d'exportation PDF qui n'apparaît que dans Safari. L'IA accélère la création initiale, c'est certain. Mais [l'étude Forrester d'avril 2026] (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) montre que la plupart des entreprises ne peuvent toujours pas transformer l'adoption de l'IA en impact mesurable, en partie parce que la partie la plus difficile n'a jamais été d'écrire du code. Il s'agit de faire fonctionner l'outil, de le mettre à jour et de le faire fonctionner correctement pendant des années. La construction est la partie la plus facile. C'est le temps de fonctionnement, les rotations d'astreinte et les corrections incrémentielles qui vous coûtent réellement.
**La confiance, la sécurité et la confidentialité des données sont des aspects sous-estimés. Lorsque vous construisez quelque chose vous-même, vous êtes responsable de la sécurité. Vous êtes responsable du cryptage au repos, de l'enregistrement des audits, des tests de pénétration, de la conformité au GDPR, de SOC 2 et de la prochaine réglementation dont personne n'a encore entendu parler. Un bon fournisseur de SaaS dispose d'une équipe entière dont le seul travail consiste à s'assurer que vos données ne se retrouvent pas à un endroit où elles ne devraient pas être. Pour la plupart des entreprises, ce n'est pas un coût qu'elles veulent supporter en interne. Et honnêtement, la plupart des outils internes que j'ai vus n'ont même pas de contrôles d'accès appropriés, sans parler d'une piste d'audit de sécurité.
La solution intermédiaire composable
Ce qui est intéressant, c'est que, de plus en plus, la réponse n'est pas "construire" ou "acheter". Il s'agit de composer. Choisissez les outils SaaS qui font bien les choses difficiles, exposent de bonnes API et vous permettent de construire autour d'eux.
C'est pourquoi les architectures de plugins sont si importantes en ce moment (et oui, c'est exactement ce dans quoi nous avons investi avec le système de plugins de Rasepi). Les produits SaaS qui prospéreront sont ceux qui disent : "Nous nous occupons du noyau dur, spécifique à un domaine, et vous personnalisez tout le reste. Vous personnalisez tout le reste". Et non pas "voici notre monolithe, à prendre ou à laisser".
[Le rapport d'avril 2026 de Forrester (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) a révélé que la plupart des entreprises ont encore du mal à transformer l'adoption de l'IA en un impact commercial mesurable. Les entreprises qui adoptent massivement l'IA sont 47 % plus susceptibles de travailler avec des partenaires consultants pour préparer leurs données et leurs systèmes. Le message est clair : la capacité de construction brute n'est pas le goulot d'étranglement. C'est le fait de savoir quoi construire et d'avoir l'infrastructure nécessaire pour le faire qui constitue la véritable contrainte.
Ce que cela signifie pour SaaS
Si vous dirigez une entreprise SaaS en 2026, je pense qu'il y a quelques vérités gênantes :
- Votre argumentaire "nous allons vous faire gagner du temps" est plus faible que jamais.** Le gain de temps était l'argument de vente classique du SaaS. Mais lorsque l'IA comprime le temps de construction de 20 à 30 %, le chiffre du "temps gagné" dans votre feuille de calcul du retour sur investissement diminue proportionnellement. Vous avez besoin d'une histoire différente.
- Les caractéristiques sont des enjeux de table, les résultats sont le produit.** Personne ne se soucie de savoir si vous avez 47 intégrations. Ce qui compte pour eux, c'est que leur documentation reste à jour, que leurs traductions soient exactes et que leur équipe utilise réellement l'outil. Le langage de Gartner sur le "flux de travail axé sur les résultats" n'est pas seulement un jargon d'analyste. C'est la direction que prend le marché.
- L'instinct de fermer sa plateforme et de rendre le changement difficile est compréhensible. Mais Gartner a explicitement averti que "les fournisseurs de SaaS traditionnels qui tentent de fermer les systèmes d'enregistrement risquent d'être contournés par les couches d'orchestration auxquelles les entreprises font davantage confiance". Ouch.
La version honnête
Je vais vous dire franchement ce que je pense de cette question. Construire ou acheter n'a jamais été une question de technologie. Il s'agissait toujours d'une question de confiance. Est-ce que je fais confiance à ce fournisseur pour comprendre mon problème suffisamment en profondeur pour que sa solution soit meilleure que celle que je pourrais bricoler ?
En 2026, la notion de "bricolage" a été considérablement améliorée. La barre de confiance s'est donc également élevée.
Pour nous, à Rasepi, cela signifie que nous ne pouvons pas nous contenter d'être un outil de documentation qui prend en charge les traductions. Nous devons être tellement bons dans les problèmes difficiles, le suivi des traductions au niveau des blocs, l'application de la fraîcheur du contenu, la complexité multi-tenant, que la construction d'un remplaçant serait vraiment pénible, même avec les meilleurs outils d'IA au monde.
C'est la nouvelle question "construire ou acheter". Il ne s'agit pas de savoir si l'on peut le construire, mais s'il faut dépenser de l'énergie pour le construire alors que quelqu'un d'autre a déjà résolu les problèmes les plus ardus.
La question n'a jamais vraiment porté sur le coût. Il s'agissait de savoir où l'on voulait consacrer son attention. Et dans un monde où la construction est bon marché, l'attention est la seule ressource rare qui reste.