Quand le code devient une commodité: La montée des sociétés AI natives

En 2003 je faisais une formation "architecte" et on m'apprenait alors que l'un des principaux problèmes que je devrais gérer à l'avenir, outre le naming et la durée de vie d'un cache, ce serait de répondre à la question Build or Buy.

Et en effet, on devait constamment trouver le bon équilibre entre construire du logiciel, ou l'acheter sur étagère. L'open source existait bien sûr, je pourrais citer Mysql ou Apache, mais il n'y avait pas autant de logiciel open source complet qu'aujourd'hui.

Avec le temps justement cet essor de l'open source a changé la donne.

Je peux aujourd'hui par exemple faire tourner une application sur un PAAS open source (coolify), utiliser metabase pour de la data analyse, openpanel pour du web analytics, listmonk pour de l'envoi de newsletter etc... Je peux faire le choix d'héberger et de faire tourner beaucoup de logiciels qui étaient auparavant uniquement disponibles en version propriétaire.

Donc à partir de là, c'était plus juste Build or Buy mais Build or Buy or Run. Le run apportant lui-même son lot de contraintes et de compromis.

Mais depuis l'an dernier, on assiste à nouveau à un changement et le problème est devenu Build, Buy, Run or Vibe (BBRV).
(vibe étant lié au vibe coding, même si aujourd'hui on s'éloigne de plus en plus du simple vibe coding pour une véritable industrialisation de l'usage de l'IA)

L'illusion des MOAT par la quantité de code

Un Moat (douve en anglais), c'est un avantage défensif durable. On essaie souvent quand on construit un logiciel de se créer un MOAT, c'est-à-dire un avantage compétitif. Pendant très longtemps, ce MOAT pouvait être simplement qu'un logiciel nécessitait trop de temps à être reconstruit, sans être crucial pour une entreprise.

Prenons par exemple un logiciel qui vous fournit la gestion de feature flag (unleash ou launchdarkly). C'est pas complexe en soi, mais c'est rarement coeur pour une entreprise. Donc dans le dilemne classique de Build or Buy, le Buy était souvent privilégié. Quelle serait la plus-value de reconstruire ça ?

Sauf que désormais, beaucoup de softs "simples" sont reproductibles avec des assistants de code boosté à l'IA.

Dit autrement, je dois désormais arbitrer entre prendre un produit sur étagère qui me coute peut-être entre 100 et 1000 euros par mois, et le fait de mobiliser un(e) ingénieur pendant une journée pour reproduire uniquement les fonctionnalités qui m'intéressent et à cela, je dois inclure le cout du run.

Et ça, c'est un énorme défi en perspective qui doit être pris en compte par chaque créateur de logiciel, et encore plus de SAAS.

La capacité à produire du code, n'est plus un avantage compétitif.

Si le code devient une commodité, est-ce que tous les SAAS sont voués à disparaître. Évidemment que non, mais on va illustrer ce point.

J'ai vu récemment passer deux initiatives pour reproduire Linkedin et qui ont été produit avec l'IA :

• https://nolto.social/ très prometteur, basé sur activitypub, self hostable, open source, et démarré avec lovable.dev (un assistant de code IA)
• https://ponos-job.eu/, plus simple, également open source, construit aussi avec IA.

Ces deux softs montrent qu'on peut refaire désormais avec des équipes de une ou deux personnes des logiciels très complets.

Pour reprendre une analogie que j'ai vu plusieurs fois sur internet, si la production de logiciel avant, était une construction puis un assemblage lent et méticuleux de briques, aujourd'hui, on peut coder rapidement des murs entiers. Ce qui limite un développeur, c'est sa compréhension métier. Mais plus un soft est connu et documenté, plus on peut rétro ingénierer facilement cette connaissance quand on a la tête bien faite et une connaissance fonctionnelle du métier.

Mais ici la barrière pour remplacer Linkedin, c'est pas le code en soi.

Avec l'IA, on est passé d'une économie de la rareté de la production (coder était difficile et cher) à une économie de la rareté de la confiance et de la distribution. Linkedin va garder, pour l'instant, cet avantage sur ces deux initiatives.

Et il existe d'autres barrières qui restent efficaces :

• l'accès exclusif à une donnée bien spécifique (Exemple Palantir)
• l'effet réseau. C'est ce qui protége Linkedin, Whatsapp ou X. Certains logiciels n'ont d'intérêt que s'ils sont utilisés par d'autres.
• des accréditations ou certifications réglementaires qui donnent accès à des marchés protégés (exemple le bancaire ou le militaire)
• l'implantation dans un écosystème (si un logiciel est déjà intégré et référencé au sein d'un écosystème existant, c'est dur de l'enlever sans perdre toutes ces intégrations, par exemple Jira, Salesforce ou Okta)
• la donnée captive (c'est proche du point précédent, nos données peuvent être "otages" d'un logiciel ce qui rend la sortie difficile
• la garantie de service (ça rejoint le fait de supporter le run, mais pour certains logiciels, on est prêt à payer pour ne pas endosser la responsabilité)
• un réseau physique, par exemple cloudflare ou amazon qui possèdent des datacenters. Forcément le physique est non réplicable.

Certains de ces items sont directement liés aussi à la capacité de distribution. Par exemple, je peux créer un ersatz de Slack ou Teams, mais je n'ai pas la capacité de distribution (force commerciale et intégration dans un écosystème) de Microsoft ou Salesforce pour le faire se diffuser partout.

Ceux qui ont la donnée (qu'ils l'achètent ou l'accumulent) gardent l'avantage. Parce qu'ils sont aussi capable de résoudre plus de cas d'usage. Et c'est pas étonnant que l'accès à cette donnée soit protégé. À l'inverse ceux qui ne font que manipuler et afficher de la donnée sont en danger.

Au delà de ca, je pense qu'on assiste à une nouvelle génération d'entreprise, les IA natives.

Des cloud natives aux IA natives

J'ai connu l'ère Cloud native en créant Malt en 2012.

Ça voulait dire qu'on n'avait rien en propre, pas de serveur, pas de bureaux. Tout était décentralisé et éclaté. C'était une entreprise purement online. Chaque brique de l'entreprise était un SAAS sur étagère.

Avec cette dématérialisation à outrance, les entreprises Cloud natives sont devenu liquides, facile à modifier et faire évoluer. La gestion des ressources se faisait par de la location. Je louais un service et je pouvais en changer "facilement", modulo des couts d'intégration bien sûr, sans devoir gérer avec des équipes internes, des réaffectations de serveurs etc...

L'informatique est devenu une forme de Lego géant.

Et pour moi, qui avait connu les entreprises non cloud natives, qui est allé coder en salle serveur directement pour reprendre la main sur une machine défaillante, ou qui a subi des pannes de clim en salle serveur ayant fait tomber toute l'infra, la différence est flagrante. De même, je suis passé d'une époque ou demander un serveur de CI pouvait prendre littéralement 3 mois, avec des formulaires d'ouverture réseau à n'en plus finir, à un simple click sur une interface.

Être cloud native c'est devenu aussi naturellement une facon simple d'épouser des concepts modernes de sécurité, comme le Zero Trust architecture qui est par définition impossible à éviter dans ce contexte. Vous ne pouvez pas faire confiance au réseau puisque votre réseau interne, c'est Internet. C'est devenu un avantage lors de la crise covid. Je n'ai pas connu, comme certaines boites, le fait de devoir faire des rotations sur les heures de login le matin parce que le réseau interne et le VPN d'entreprise n'était pas dimensionné pour autant d'accès externes. Je n'ai pas connu l'obligation de revenir au bureau pour récupérer du courrier, ou revalider mon pc sur le réseau interne de la boite.

Et je peux vous dire que j'ai vu passer des gens dans la boite qui venaient de boites traditionnelles et qui n'ont jamais réussi à comprendre cette culture, toujours à se questionner sur le nombre de services utilisé par la boite et incapable d'appréhender la vraie nature de ce que nous étions.

Je sais que c'est encore dur, même aujourd'hui, de faire prendre conscience que le Cloud a littéralement été l'un des moteurs majeurs de la tech sur la décennie 2010. Beaucoup voient dans le cloud une simple entourloupe marketing, le fait de déplacer ses serveurs chez quelqu'un d'autre, une simple infogérance. En 2026 il y a encore beaucoup d'entreprises qui ne sont pas cloud natives. Et c'est normal. On ne passe pas d'un monde à l'autre d'un claquement de doigt, si même c'est possible.

Quand je dis que ça a été moteur, il faut comprendre que ça a créé de la souplesse et donc de la vitesse, vitesse qui a été déterminante pour toutes les boites post 2008 (en France, Blablacar, doctolib, Malt, Backmarket etc..). Ce changement technologique a aussi permis de créer beaucoup d'opportunités pour reconstruire des services existants, mais sous forme de briques en ligne (les fameux SAAS).

Mais aujourd'hui, on voit apparaitre des entreprises IA natives. Des entreprises pour lesquelles la production de code est devenu une commodité. La capacité de production a drastiquement augmenté.

Si le Cloud Native a "simplifié" l'infrastructure, l'IA est en train de "simplifier" la mise en œuvre.

(* Et oui, je sais, simplifier est sans doute un mauvais terme parce que faire tourner dans le cloud, ou produire du code de bonne qualité avec une IA n'est pas si simple que ça)

• 2010 : On a tué la complexité de l'infra (le hardware).
• 2024+ : On tue la complexité de l'implémentation (le software).

Conséquence : Le développeur "IA Native" devient un architecte d'intention plutôt qu'un ouvrier du code.

Le choc culturel

De la même façon qu'avec le Cloud, l'IA va créer de nombreuses opportunités. Je suis prêt à parier qu'on va voir de plus en plus des initiatives (comme celle de linkedin cité plus haut) où des softs déjà existants vont se faire totalement recréer par des entreprises avec 10 ou même 100x moins de gens, sans parler des nombreux projets open source qui vont eux-aussi naitre pour remplacer des softs "commoditaire", comme par exemple la gestion des feature flags dont je parlais plus haut.

Donc ça, c'est le premier choc. Il faut s'attendre à voir émerger beaucoup de compétiteurs très rapides dans les années qui arrivent face à des softs bien établis.

Mais il existe un corrolaire de ça, car de la même façon qu'en 2026 on a encore beaucoup d'entreprises non cloud natives et qui ne le seront jamais, beaucoup d'entreprises ne deviendront pas IA natives sans heurts.

Oui certains softs vont garder de l'avance, mais une entreprise IA native va pouvoir lutter sur les prix (le cout de production étant moindre) ou faire plus de marge, donc plus d'investissement.

Comme je le disais juste avant, j'imagine peu de boites "non IA natives" devenir IA natives, parce que ça aurait des impacts sociaux dans l'entreprise gigantesques. C'est une question de culture, la culture étant la facon dont on répond systématiquement à un problème donné. Une boîte IA Native ne cherche pas à réduire ses coûts de 20%, elle cherche à opérer avec une structure de coût fondamentalement différente (10x ou 100x moins de staff pour le même résultat).

Bref, c'est pas "juste" les boites qui font de l'IA qui vont représenter la nouvelle génération de startups post 2020, mais sans doute aussi tout un tas de petites entreprises très lean, avec peu de gens et qui vont frapper de plein fouet de nombreux business bien établis.

Et s'il y a un profil qui devrait tirer son épingle du jeu, c'est le Product engineer : la personne capable de comprendre les problèmes à résoudre et de se mettre à la place de l'utilisateur.

Et vous, dans vos roadmaps actuelles, quelle portion de votre logiciel est déjà devenue une "commodité" que l'IA pourrait reconstruire en un week-end ? Quel est le vrai rempart qui vous restera demain ?