L’ère où les tests deviennent le nouveau moat
(saewitz.com)-
Le paradoxe du succès : à mesure qu’un projet grandit, il se retrouve lesté par la rétrocompatibilité et par une énorme base de code (le navire de Thésée). À l’inverse, un concurrent peut entraîner une IA sur les spécifications d’API, la documentation et les tests d’un projet existant, puis en extraire la valeur essentielle pour produire en un instant une « version plus légère et plus moderne ».
-
Cas Cloudflare vs Vercel : Cloudflare a utilisé l’imposante documentation et la suite de tests de Next.js accumulées par Vercel pendant des années pour construire, en une seule semaine, un runtime compatible Next.js, allégé et basé sur Vite. (Il est désormais utilisé aussi sur cio.gov, un site du gouvernement américain.)
-
Les tests comme actif stratégique : autrefois, c’était le code lui-même qui comptait ; désormais, ce sont le « contrat logiciel » et les « cas de test » qui sont devenus les actifs les plus précieux. Les rendre publics revient à fournir à un concurrent un plan d’une précision redoutable pour cloner mon service tel quel.
-
La clairvoyance de SQLite : SQLite rend son code public, mais conserve privée son immense suite de tests — 590 fois plus volumineuse que le code source lui-même (92 millions de lignes). C’est le « moat » qui lui permet de préserver l’écosystème open source tout en gardant une défense commerciale.
-
Conclusion : à l’ère de l’IA, les entreprises d’open source commercial sont arrivées à un moment où elles doivent trancher entre « l’altruisme total (open source) » et la survie du business. Beaucoup de projets devraient désormais, comme SQLite, fermer leur code de test afin de bâtir leur propre barrière technologique.
19 commentaires
Dans cette perspective, il se pourrait même que des documents comme les ADR (Architecture Decision Records) ou les CIR (Change Intent Records) soient considérés comme plus précieux que le code lui-même.
C’est vraiment assez impressionnant. Le texte est court, mais on comprend tout de suite. La sécurité des tests pourrait même être plus importante que celle du code source.
J’ai l’impression qu’il s’agit surtout de dire qu’il ne faut pas négliger les tests e2e, mais je serais curieux de savoir ce que les autres en pensent.
Je ne suis absolument pas développeur... mais je lui fais écrire un peu de code juste pour le plaisir de bidouiller avec l’IA, et sans même que je le demande, elle créait et conservait plein de code de test ; donc c’était pour cette raison. Quand je lui ai demandé à quoi ça servait au juste, elle m’a répondu que c’était nécessaire quand elle écrit du code et qu’il ne fallait pas les supprimer.
Oh... je crois que c'est vrai.
L’approche de SQLite est vraiment impressionnante. Garder privée une suite de tests 590 fois plus volumineuse que le code, cela signifie au fond que « la vraie valeur d’un logiciel réside dans sa spécification de fonctionnement ».
En pratique, quand on crée aujourd’hui des projets avec des outils de codage IA, s’il existe le README du projet, la documentation API et les tests, on peut reproduire les fonctionnalités essentielles à une vitesse étonnante. C’est ce que j’ai ressenti en gérant moi-même 7 projets : paradoxalement, plus un projet est bien testé, plus il est facile à répliquer.
Cela dit, il y a un point négligé dans le cas Cloudflare vs Vercel : « répliquer » et « exploiter » sont deux problèmes totalement différents. Pour reproduire les cas limites de Next.js, l’écosystème de plugins et jusqu’à la dépendance à la communauté, les tests seuls ne suffisent pas. Au final, j’ai l’impression que le moat réside plutôt dans la combinaison du code de test, de la communauté et du savoir-faire opérationnel.
En tant que développeur solo, j’exploite 7 projets, et cet article me parle douloureusement.
Grâce aux outils de code IA, la vitesse de développement initiale est devenue folle, mais le code accumulé rapidement sans tests finit par se transformer en enfer du refactoring. Surtout quand on exploite plusieurs services en même temps, les projets sans tests deviennent si effrayants qu’on hésite à y toucher, de peur qu’en modifiant une seule fonctionnalité, quelque chose casse ailleurs.
La métaphore « tests = moat » est juste. Un concurrent peut copier le code, mais il lui sera difficile de reproduire jusqu’à une suite de tests couvrant des milliers de cas limites. C’est d’autant plus vrai que, si l’IA sait bien générer du code, créer des scénarios de test pertinents reste encore un domaine où les connaissances métier humaines sont nécessaires.
Mais selon les domaines, il arrive aussi que le code de test ait une couverture presque inexistante, donc ça fait réfléchir. J’ai aussi l’impression que, de ce côté-là, ils n’arrivent pas encore à produire d’aussi bon code que dans d’autres domaines.
Pourriez-vous me dire de quel domaine il s’agit, par hasard ? (Ce n’est pas pour polémiquer, c’est vraiment de la pure curiosité.)
Le domaine dans lequel je travaille n’est pas extrême à ce point non plus, mais je fais de la recherche et du développement en IA.
En plus des frameworks couramment utilisés, il arrive aussi que l’environnement cible où le modèle est réellement déployé soit différent de celui dans lequel il a été entraîné.
Il arrive aussi que certaines opérations spécifiques ne soient pas prises en charge, et qu’il faille donc créer des opérations personnalisées selon la plateforme. Dans ce cas, il est souvent impossible de tester directement dans l’environnement de développement.
Il m’arrive aussi de modéliser directement des modèles ; on peut écrire des tests avec certaines données, mais selon le dataset, les valeurs varient de manière probabiliste, et des phénomènes comme une explosion des valeurs à un moment donné sont difficiles à couvrir avec du code de test.
J’imagine qu’il existe sans doute pas mal d’environnements où les tests sont encore plus difficiles que dans mon cas.
C’est simplement mon avis, mais j’imagine que cela concerne surtout les domaines où l’on utilise souvent des notebooks, ceux de l’IA où les réponses sont probabilistes, ou encore le développement de clients de jeux.
C’est aussi quelque chose dont je parle souvent autour de moi : au final, comme il sera difficile plus tard de passer en revue tout le code, je pense que si on ne teste pas systématiquement les logiques vraiment importantes, on risque de gros problèmes.
Cela a aussi été ajouté en bas de l’article, et il a été dit que tldraw exécute également ses tests en privé (apparemment c’était une blague).
https://github.com/tldraw/tldraw/issues/8082
Si vous regardez Comment SQLite est testé,
SQLite est entièrement open source, mais il possède un code de test 590 fois plus volumineux que le code source, et celui-ci est totalement privé.
Il dispose de 100 % de couverture des branches, de plusieurs millions de cas de test, et exécute plus d’un milliard de tests de mutation.
Je suis allé lire le fil, et apparemment ils disent que c'est « une blague ».
On dirait que c’était un test Joke.
Ah, d’accord. Je n’avais regardé que le haut, haha.
L’idée clé selon laquelle « les tests priment sur le code source » me semble tout à fait juste. En revanche, je ne sais pas si une stratégie consistant à ne pas ouvrir les tests tout en ne faisant que de l’open source sera vraiment efficace. J’ai aussi l’impression qu’ils seraient capables d’extraire très bien les cas de test à partir du code source...
Ils le font mal.
https://fr.news.hada.io/topic?id=26988
Cela semble lié à cet article. Quand on fait de l’open source, on pourrait désormais devenir plus prudent quant à la publication du code de test.