On ne paie plus les développeurs pour écrire du code
Transcript
En février, une étude tenitruyante a fait jaser dans le monde de l'IA.
6 000 patrons expliquent que les LLM n'ont eu absolument aucun impact sur la productivité.
Devant les grandes promesses des labodias, de ceux qui prédisent la fin du travail de bureau, on envie de dire où sont les résultats.
Ça paraît contradictoire.
Surtout que, en observant les développeurs autour de moi, j'ai au contraire l'impression que depuis à peu près décembre 2025, on a passé une sorte de point de bascule.
Tous les développeurs et entreprises que je connais qui utilisent l'IA de manière intensive, en particulier ce qu'on appelle les orchestrateurs,
comme Clut Code ou Codex, sont en train de se métamorphoser sous nos yeux.
Alors qu'est-ce qu'ils font de différent ?
Pour répondre à ces questions complexes, j'ai invité Quentin Adam, qui avec son entreprise de 70 développeurs et son architecture ultra critique, où rien ne doit être laissé au hasard, est plutôt bien placé pour nous éclairer.
Il va nous raconter comment il est passé de carrément dubitatif,
a beaucoup moins d'hubitatif jusqu'à même repenser sa boîte de A à Z et avoir un avis bien tranché.
Mais juste avant, j'ai un message justement pour les entrepreneurs et les développeurs qui me regardent parce qu'après cette vidéo, vous allez vouloir faire pareil dans votre boîte.
Et notre partenaire Mammouth AI, une boîte française, peut sûrement vous aider.
Avec leur offre entreprise, vous pouvez donner à toutes vos équipes l'accès au meilleur modèle d'IA comme Claude GPT, Gemini Mistral,
dans une seule interface.
Et surtout, vous pourrez utiliser leur orchestrateur Mammouth Code dans votre terminal avec le bénéfice de pouvoir choisir n'importe quel LLM.
Vous aurez une interface admine pour suivre chaque collaborateur et maîtriser vos coûts.
Et là où c'est rassurant, c'est que aucun prompt n'est stocké ni utilisé pour entraîner les modèles et c'est conforme au RGPD.
Plus de 300 entreprises et administrations publiques utilisent déjà Mammouth AI.
Je vous mets en description le lien et une vidéo que j'ai fait avec le co-fondateur pour découvrir la boîte.
Et sans plus attendre,
On reprend.
Est-ce que tu peux nous partager ?
Est-ce que toi, ta première impression a été sur l'IA et tout ça ?
Alors, la première impression quand on a commencé à me parler de l'IA dans le code, c'était l'IA.
Un an et demi, deux ans, ma première impression, ça a été de dire, c'est un perroquet statistique et ton machin.
Donc, ça va quand même produire essentiellement de la merde.
Et d'ailleurs, au début, un GPT produisait du code qui compilait pas.
parce qu'ils calculaient la possibilité d'un mot derrière et que la possibilité du mot derrière en fonction de son set d'entraînement n'était pas nécessairement hyper pertinent.
Et progressivement ils ont un raffiné leur méthode d'entraînement, deux ils ont commencé à mettre des boucles de rétro-action dans les différents systèmes, mais ça restait compliqué parce que
t'as cette fameuse histoire de contexte dans l'IA.
Pour vous compreniez, c'est dans l'IA, globalement, quand vous envoyez une requête de conversation, vous envoyez la conversation, le truc vous fournit une réponse.
Quand vous renvoyez une réponse, ce qui s'est passé en dessous, c'est que vous venez de renvoyer toute la conversation précédente, et lui ressort un bloc supplémentaire de la conversation qui est votre réponse.
Mais du coup,
Ça, cette taille de conversation augmentant dans le temps, vous avez toujours à un moment un problème de ce qu'on appelle le contexte qui est la quantité de textes de token mais bon globalement dans le cas présent de textes que vous pouvez mettre dans le modèle en entrée.
Et donc, du coup, globalement, tu ne pouvais pas faire grossir énormément les choses, parce que ta conversation prend trop de place par rapport au nombre de lignes de codes que tu vas sortir, donc effectivement, tu pouvais fondre des scripts.
Et t'as arrivé le mode agentique, qui est ce modèle où on va avoir plusieurs questions qui sont posées dans le bon ordre par quelque chose qui fait le tri dans ce qu'on doit arriver à faire dans le code en local, et qui a commencé à faire des choses.
Et il y a après en 18 mois, j'ai commencé à tester des trucs
où je me suis dit ah le machin c'est codé.
Mieux, la façon dont il vient de coder ça est factuellement mieux que ce que moi j'aurais codé et surtout il l'a fait plus vite et là où j'ai pas été d'accord je lui ai dit il l'a corrigé et en termes purement temporelles on vient d'économiser quelques heures.
Donc pour l'instant le truc reste con mais je me suis dit ah je pense qu'il va se passer un truc.
parce que c'est des boucles de rétroaction qui vont être très rapides.
Et c'est la fameuse histoire de quand tu sais, on a appris Alia à jouer à Go.
Tant qu'on montrait Alia, deux humains qui jouaient du Go, ça apprend le temps que deux humains jouaient une partie de Go.
Au moment où tu mets deux IA en concurrence à jouer au Go, ils vont vachement vite et ils font des millions de parties et ils deviennent très bons.
Et c'est un peu ça en fait, l'enjeu du code informatique, c'est que à la différence de d'autres trucs, écrire un rapport, un machin, tu le fais juger par un de main.
La basité mesurable, précise.
Là du code, tu sais si il marche ou si il marche pas, s'il compile, s'il compile
pas.
Exactement.
Et donc en fait, il est évident qu'on va prendre une accélération.
Et j'ai commencé à pousser tout le temps
là-dedans.
Toi, t'as boîte déjà à l'époque ?
Vous développez quel genre de système parce que c'est ça qui est intéressant aussi c'est que dès qu'on va parler de système complexe, ce sur quoi travaille la plupart des développeurs en réalité c'est de la rechercher développement où c'est crée des briques plus élémentaires plus difficiles.
où l'erreur n'est moins permise, ils ont dit « ça, l'IA, elle ne peut pas trop y toucher globalement ».
Toi, pour expliquer dans les contextes, claveur cloud vous faites quoi ?
Et est-ce que tu peux vibe-coder un truc du code bancal
?
Donc claveur existe depuis un peu plus de 15 ans, et ce qu'on fait, c'est un cloud provider.
Nous, on fait le logiciel du cloud, donc ça va sur nos serveurs ou les serveurs des autres, claveur cloud, on est vraiment versatile.
Et ce qui est intéressant, c'est qu'on fait toutes les stacks.
On peut descendre très très bas dans l'OS, tout comme on monte progressivement dans des couches, donc on a notre propre base de données, on opère aussi d'autres bases de données, et on a du coup des logiciels de trégestion, parce qu'il faut qu'on gère le paiement des gens, comptabiliser un compte, pas un compte.
Et puis...
Quand tu dis que vous avez votre base
de données, c'est pas que vous utilisez une base de données, c'est
que vous avez développé... Ouais, on a une base de données maison basée sur un truc qui s'appelle fondation
DB.
Alors du coup, on devient très curieux de dire
Il y a 18 mois, quand tu commences à t'intéresser à ça, j'imagine que tu peux en parler avec tes développeurs, etc. Qu'est-ce qui marche bien ?
Qu'est-ce qui ne marche pas bien ?
Qu'est-ce qui m'en s'est reçu
?
En fait, moi, je n'ai pas des use cases que j'ai trouvées marchées pas bien.
Globalement, l'IASM a bien bossé quand tu disons des spécifications claires.
Par exemple, tu lui dis que j'ai tel protocole qu'a jamais été implémenté dans tel langage.
Mais ça se passe bien, le doigt du protocole est précis, le truc t'implémente le protocole, il se pose pas trop de questions.
Quand tu commences à pas trop savoir ce que tu veux, là ça part en caca.
Et dès le début, on se dit que c'est assez cool et on s'en sert au début pour faire du tooling interne joué.
Et assez rapidement, on se rend compte d'un truc plus le langager.
Contrain, mieux, il est bon.
Pour une raison qui est très conne.
En fait, quand il écrit du code, il comprend pas très bien ce qu'il écrit.
C'est un LLM, ça reste assez con, un LLM.
Par contre, si au moment de la compilation, il a une compilation très détendue.
JavaScript, Go, tu vois, ce sont des compilations qui sont pas très fermées, qui n'oblient pas grand-chose.
En fait, ça va compiler et après on va exécuter le programme, on verra si ça marche.
Et donc là, tu rentres dans un processus plus de tests.
Si tu vas vers des compilations plus strictes, avec des typages plus forts, une gestion de la rame qui est mieux, genre par exemple Rust, avec une sortie du compilateur qui est assez, enfin le compilateur Rust il est chiant et il te parle, il te dit bah ça t'as pas le droit de le faire, ça t'as pas le droit de le faire.
Mais en fait ton élément il sait dire ça, il sait le comprendre et il sait le corriger.
Et donc ta boucle de rétroaction entre les deux va devenir hyper-méliorative.
Super intéressant, parce que surtout à cette époque là justement où on commence à tester les LLM sur les langages, l'idée répandue c'est que les LLM sont meilleurs.
Là où il y a les plus gros jeux de données, et à l'époque c'est JavaScript et Python.
Donc en gros les premiers LLM sont globalement vachement plus performants en JavaScript et Python que sur tout le reste parce que c'est là où il y a la masse de données humaines.
Mais en fait, c'est pas si
bien.
En fait, il est bon à 80%, mais pour te one-shotter quelque chose qui marche, il est pas si bon que ça.
Alors après, t'as un problème de qualité de jeu de données effectivement.
Le problème qu'on a souvent eu en Java par exemple, c'est des trucs qui s'appellent mon fichier point Java, il y en a des tonnes sur 23 putain de versions de Java.
Résultat des courses, dès quoi il t'écrit du Java 8 en fait, le machin, parce que c'est logique.
Et donc en fait, c'est un peu paradoxal, mais il fallait des langages suffisamment vieux pour avoir un gros dataset.
mais pas trop vieux pour pas avoir eu 120 itérations qui en fait vont perdre le machin.
Et moi je trouve que un des langages qui s'en est le mieux sorti en fait à ce moment là c'est Rust.
Parce que Rust n'a pas eu de changement cassant, le langage a 10-15 ans, c'est assez uniforme et le compiler est hyper con.
Donc du coup t'as un langage qui se comporte bien avec un bon dataset.
Et
donc vous sur du Rust ça
vous arrange plutôt pas mal puisque si mes souvenirs sont bons vous en faisiez déjà beaucoup.
On en faisait déjà énormément.
En fait, Rust pour moi a plusieurs intérêts, c'est qu'un, il est vachement safe sur la mémoire, deux, il rasterise énormément de choses, il a une bonne performance, la qualité globale des librairies est bonne, et en fait, il se vibe code hyper bien.
Donc si vous commencez le vibe coding, ma recommandation, c'est fait tout en Rust.
Et donc vous êtes bien placé en tout cas, à ce moment-là, pour mettre en place justement du développement assisté par IA.
La question la plus intéressante je trouve c'est à partir du moment où t'as commencé à déployer ça, c'est quoi les changements que t'as observé à ce moment-là ?
Et de ce que j'ai compris par exemple, t'as vu des changements du côté des seniors et ça ça m'intéresse quand on
parle.
La première chose c'est que je vais voir les développeurs genre d'y utiliser ça et donc je fais ce qu'on fait dans une boîte normalement, je communique au global.
Et tout le monde s'en fout.
Mais vraiment, c'est très amusant parce que les développeurs qui ont changé le boulot d'absolument tout le monde ces 30 dernières années sont d'une résistance aux changements mais monumentale.
Ils veulent pas en entendre parler, ça les gonfle, ils ont peur.
Et donc pour être franc, j'ai fait un truc au début, j'ai été convainc les gens un par un, notamment les Techlead.
Donc je me pointais dans des bureaux, je prenais l'avion, j'y allais, je me pointais dans les bureaux Clever, j'allais m'asseoir à côté d'un mec, j'ai dit t'attester ça, non.
Ça te dit, on le teste ensemble, non ?
Si, si, je t'assure.
Et au début, ce n'était pas convaincu.
En général, après, je me tirais passer un coup de téléphone et il revenait.
Et moi, j'ai eu le cas avec un ami qui...
Vraiment, je suis arrivé, je lui ai dit, on le teste ensemble.
Il m'a fait, écoute, je sais ce que tu en penses, mais là, j'ai du travail.
J'ai dit, si, si, on le teste ensemble.
Je me tire finir un coup de téléphone, je reviens.
Il me dit, le machin vient de m'exécuter mes cinq dernières semaines de boulot en deux heures.
Et il a mieux codé que moi.
Et donc, la première chose, c'est la prise de conscience qui, effectivement, ça a été long d'emmener les gens dedans.
Mais une fois qu'on avait créé cette culture-là, on a commencé à avancer.
Et là, j'ai tenté de faire ce qu'on fait de toutes les boîtes, c'est-à-dire dire, bon, on va faire un outil d'entreprise, donc j'étais tombé fan de Windsor, flâchant, et ça va trop vite.
En gros, t'as essayé de faire un truc très descendant où t'as dit, voilà, l'outil qu'on va utiliser.
Ouais, c'est ça.
Mais en fait, connerie.
Ça va trop vite.
Incapable d'aller à la urine du marché.
Donc j'ai envoyé un mail qui était dans les notes de frais.
Vous avez un nouveau truc qui s'appelle intelligence artificielle.
Achetez ce que vous voulez.
Vous savez ce que vous avez le droit de mettre n'importe où, ce que vous avez le droit de mettre n'importe où.
Enfin, c'était des critères hautes dans la boîte.
Mais globalement, achetez ce que vous voulez, quand vous voulez.
vous le payez, vous faites une note de frais.
Je vous interdit de prendre des plans annuels parce qu'en fait, statistiquement, aucun des outils qu'on utilise, on les ai utilisés un an parce que ça va trop vite.
Testez tout ce que vous voulez et on se retrouve une fois de temps en temps pour partager les expériences parce que ça va trop vite.
et hésitez pas à y aller.
Donc là ça a vraiment en termes d'outils, j'ai renoncé à essayer d'avoir une politique unifiée parce que pas possible, ça va trop vite.
Vous y arriverait pas en fait, c'est pas possible.
La seconde chose, c'est qu'en fait c'est les seniors qui vont adapter le plus facilement parce que tu prends des gens qui sont capés, qui gèrent 40 personnes, en fait ils n'ont jamais le temps de coder.
Et là ils ont pu faire des pocs en disant « Attends, plutôt que de demander à mes juniors, je vais faire un poc ».
Et il s'est passé un truc, c'est que tous les seniors sont devenus monstrueusement productifs.
C'est-à-dire qu'ils se sont mis à coder en plus de gérer leurs équipes.
Dans le cas de certains, ils te disent « j'ai jamais aussi bien codé de ma vie ».
Le code n'a jamais été aussi propre.
Et ça c'est assez intéressant parce qu'ils peuvent de nouveau plus facilement formaliser leurs idées que quand ils avaient tu vois à faire un boulot où fallait aller expliquer avec des gens, faire des réunions, écrire des documents de spec, là en fait tu formalises ton truc, t'envoies et tu bosses.
Et surtout ce qui est intéressant c'est que tu vas pouvoir faire en code
les bonnes pratiques qu'on ne pouvait pas faire parce qu'on n'avait pas assez le temps etc et qu'on faisait tous tout à l'arrache tout le temps et là on va pouvoir pas remettre les bonnes pratiques sur le terrain c'est à dire ça c'est intéressant.
Bah ton code si tu dis à ton agent bah produisant un programme il produit un programme puis après toi tu test le programme le programme fait pas ce que tu veux tu redis à ton agent de corriger etc qu'est ce que tu viens de faire tu viens de larguer la partie fun du truc le code à ton agent et toi tu dis un testeur
En vrai, ce n'est pas le cher pays pour le testeur, tu fais chier.
Du coup, tu vas faire quoi ?
Tu vas l'emmerder pour qu'ils fassent des tests.
Donc la première chose, c'est les fameux tests unitaires.
Pour ceux qui ne sont pas
développeurs, c'est un moyen de vérifier que telle portion de code, dans différentes situations, produit un résultat prévisible
intelligible.
Exactement.
Ce n'est pas un usage métier, ce n'est pas comme si un humain l'utilisait.
Par contre, si vous avez un objet de calcul de tarification compliquée,
théoriquement selon tel paramètre vous allez toujours avoir le même montant de factures et donc ça c'est éligible à un test unitaire et donc du coup ça vous permet de vérifier que vous cassez pas des trucs fondamentaux.
C'est déjà utile mais ça le devient encore plus quand tu
codes avec des agents.
Bah oui parce que du coup tu écris des tests unitaires, tu écris des specs, tu lui dis ensuite bah fais le code et tant que les tests ne passent pas, pas de faire foutre.
Et donc progressivement tu vas pouvoir rentrer dans des tests de plus en plus poussé.
Donc le niveau zéro des tests c'est le test unitaire.
Ensuite, t'as ce qu'on appelle les tests d'intégration.
Tests d'intégration, c'est le truc qui te permet de savoir que tu te connectes bien une base de données à une API et un machin.
Et ça, notamment la conteneurisation avait amené beaucoup d'outils pour ça, notamment un truc qui s'appelle TestContainer, par exemple, qui te permet de bouter des API, des machins, des trucs qui vont te permettre de vérifier que ton programme communique bien avec le monde extérieur.
Là où, à chaque fois que tu te lances dans du test, dans un truc ou c'est toi qui écris le code, ça prend du temps, tu te poses toujours la question d'aller faire ce qu'on appelle le MOC.
Alors, le MOC, c'est quand tu crées un programme,
qui se comportent comme devrait se comporter un autre programme mais qui est simple et qui est juste fait pour faire les tests.
Notamment parce qu'imagine que tu veux y faire des tests unitaires sur des comportements d'un agent boursier par exemple.
tu ne peux pas faire des tests unitaires en utilisant les données de la bourse enterelle, puisqu'il faut que tu puisses prédire les montants que tu vas injecter dans le système, si tu veux vérifier que le système va se comporter comme tu veux.
Tu simules une bourse, quoi, en fait.
C'est ça.
Et donc, avec tes tests d'intégration, tu vas mettre soit des vrais logiciels configurés pour soit du MOC, et tu vas t'assurer que ton programme tient là.
Ce qui est intéressant, c'est que là où avant, construire des MOC, construire des tests, c'était énormément de travail.
Et donc, tu t'arbitrerais toujours entre
Est-ce que je suis sûr que j'ai besoin de ça ou pas dans mes tests ?
Là, comme ça te coûte beaucoup moins cher et que, par contre, ça te permet de compresser ta boucle de rétroaction, bah tu le fais.
Donc ce qui était une bonne pratique que tu devais arbitrer avant
devient en fait...
Elle coûte plus très cher.
Ben, c'est même un gain d'argent.
Parce qu'en fait ça te permettrait de réduire ta boucle.
Et donc tu dois améliorer en permanence ta base de tests.
Donc tes tests d'intégration vont être un second step.
Et ensuite tu vas commencer à faire des tests plus compliqués.
Donc nous on a des tests de ce qu'on appelle de la simulation.
Donc ça c'est un truc qui vient de fondation DB.
fondation DB c'est un système distribué.
Ton système distribué tu peux faire autant de tests unitaires que tu veux.
Le problème de ton système distribué c'est qu'après il est installé sur 960 machines et t'as une machine là-bas qui se met à faire 30% d'écriture en mémoire qui merde parce que ta barrette de rame est en train de crever.
Ouais les bugs Quota ils sont
pas visibles sur
juste
une instance
en fait.
C'est ça.
Tes bugs sont liés à la distribution.
L'enfer de ton métier si je peux me permettre.
Ah ben non mais ça...
Mais c'est aussi ce qui est de rôle, en fait, pour être tout à fait franc.
Mais du coup, on a un truc dans fondation DB, quel simulateur.
Le simulateur, il dit « sur tel Bécane, je vais me mettre à perdre 20% des paquets dans le réseau, sur tel Bécane, je l'arrête et je l'arr lance, on verra comment ça se met.
Est-ce que le machin embarque et se met à répondre de la merde dans le cluster ou pas ? »
Il se coupe, il le fait avec de l'aléatoire, plein, plein de cas.
Il essaie d'imaginer des cas.
Enfin, le simulateur est très, très complet.
Et en fait, on s'est dit, on va essayer de porter la simulation dans l'ensemble du système.
Pourquoi ?
Parce que si tu fais des tests où tu as un simulateur formel, donc après, tu as des garanties mathématiques, je ne vais pas vous prendre la tête avec ça, mais la simulation est un domaine entier des mathématiques, ou du coup, on peut avoir des preuves mathématiques formelles qu'on a testées tous les cas bizarres.
Et ça, en fait, enfin, si tu les testes à la main, enfin, c'est des centaines d'heures, enfin, c'est ingérable.
Là, à chaque comite dans le GitLab,
Ça va partir en simulation, alors ça grille des chiets de CPU, on est d'accord avec ça, mais ton système, t'es certain que sous une contrainte donnée, t'auras détecté son bug, ce qui va écrire en plus un rapport de bug, qui va être posté dans un issue, dépilé par un autre agent, qui va aller le résoudre.
Et ça, c'est fascinant parce qu'on réalise que ce n'est pas juste une histoire de...
Il faut que les développeurs aient accès à des nouveaux lisiats, à des nouveaux agents, et voilà.
Et c'est ça le changement.
Maintenant, c'est lié à plein de choses tout autour.
C'est-à-dire que toi, t'as modifié en profondeur le fonctionnement même de la boîte et de la manière dont le logiciel est à la fois codé mais aussi vérifié, testé, validé pour ce nouveau paradigme-là.
C'est-à-dire que si tu veux tirer les meilleurs résultats, en gros, ce n'est pas juste filer un accès, un logiciel à tes défois.
Mais as-tu vraiment le choix que de tirer les meilleurs résultats ?
Parce qu'en fait, le problème, c'est que tout le monde va le prendre, le bump de productivité et de monter en qualité.
Donc si tu ne suis pas, tu auras un problème.
Par contre, si tu suis en avance, tu vas gagner des gains de productivité et donc tu vas gagner des parts de marché, si t'es bon.
Et donc, l'histoire, c'est qu'on va très rapidement, j'explique aux gens, en fait, notre métier a changé.
Et c'est pas un problème de choix, en fait.
Ça y est, notre métier a changé.
C'est un fait.
Et maintenant, il faut qu'on avance.
Parce qu'en fait, le coût du logiciel va baisser, et l'exigence de qualité va devenir terrible.
Parce que, par contre, ce que c'est faire ton programme, c'est faire des choses qu'avant, tu pouvais pas faire.
Oui,
tu
dis qu'il faut pas considérer que l'IA c'est un junior.
Oui.
En fait, ce que j'explique aux gens, c'est que l'IA est inhumaine.
Donc il faut lui demander des tâches inhumaines.
Nous on a un des gros monolithes de la boîte qui est codé et t'as à peu près 30 personnes qui interviennent dessus à la semaine.
Et donc t'as une réunion de synchronisation lundi où tous les 30 ne viennent pas, t'as les chefs des différents bouts qui viennent, puis ceux qui ont un truc à y discuter.
Mais en fait la réunion a du mal à être efficace parce que en fait t'as des gens qui parlent d'un bout de réseau, des gens qui parlent de DB, des gens qui parlent de...
Enfin ils ont pas toujours des trucs à se dire et ce qui est important c'est d'identifier ce qu'ils ont à se dire.
Et bien là, au lieu de dire à juste lia table du code, ce que j'ai fait c'est complètement différent.
Je lui ai dit, tu prends toutes les branches de code sur lesquelles les mecs boss.
Les résultats détestent et tu les compares.
T'essayes de voir là où tous les tests unitaires chient les uns après les autres, ce qu'elle a l'air difficile, ce qu'elle a l'air de bien se passer, les commentaires dans les pairs ou les issues où il y en a beaucoup, les mecs sont en train de s'engueuler ou pas, il y a une décision d'architecture à prendre et manifestement là par écrit, les esprits sont en train de s'échauffer alors que si on le fait à la réunion ça ira probablement mieux.
Tu lis mes mails, tu lis Slack, tu lis tout ça, de façon à essayer de comprendre où sont les points de tension entre les gens, où sont les points d'incompréhension, etc. Et le travail documentaire que j'ai incité, c'est 3 ou 4 jours de boulot, ce qui n'a aucun sens si tu fais une réunion toutes les semaines, enfin c'est ingérable, mais c'est 20 minutes d'exécution d'une IA.
Et donc il te sort un document de préparation de la réunion,
qui est hyper qualifié et qui te permet de rendre la réunion efficace parce que tu vas parler des sujets qui sont intéressants réellement pour les gens.
Et là, votre IA, vous venez lui demander une tâche qui est inhumaine, et là, vous l'avez rendu efficace.
Et comme tu dis, c'est inhumain parce que, en fait, dans plein de boîtes, il y a toujours des vieux dossiers, des trucs qu'on a mis un peu sous le tapis.
Tout le monde sait que
soit telle zone, il faudrait entièrement
la refaire.
Ou on voudrait migrer de langage mais c'est trop tard, la dette technique est trop élevée etc. Est-ce que ça fait pas aussi partie de ce truc inhumain qui n'a pas la plus grosse valeur ajoutée d'intelligence ?
Parce que je sais pas, c'est porter telle librairie de JavaScript à Rust par exemple.
Est-ce que c'est le genre de truc où toi tu penses que
C'est des bons candidats,
justement.
C'est littéralement ce qu'on fait.
C'est-à-dire que, au début, j'ai été incitatif chez Clever, puis plus en plus pressant, puis vers la fin de l'an dernier, j'ai été un peu, genre, bah écoutez, soit vous migrez de votre façon de bosser, soit vous n'avez pas envie de vous mettre à l'IA.
On a perdu à peu près de 2% de la masse sur ce truc, parce que c'est ridicule, tu vois.
Oui, c'est pas
tant.
Par exemple, tu n'as pas annoncé de plan de licenciement.
Non, je le rends.
J'ai annoncé qu'on embauchait des mecs.
Et puis toi, tu as une expérience particulière.
Tu es en train de te battre sur un game qui est le cloud où, en face de toi, tu es un petit David quand même et il y a des gros Goliaths.
Oui mais mes concurrents s'appellent Microsoft, Amazon et Google, donc des gens tout petits.
Si justement je fais l'avocat du diable, le développeur ou qui est peut-être un petit peu dubitatif, et qu'on voit souvent d'ailleurs dès qu'il y a des discussions autour de ça qui sont intéressantes, ils vont te dire ok c'est super tout ce que tu me dis, mais en fait ça va pondre du code qui est immantenable, qui n'est pas du tout cali,
Et en fait, la démo est sympa, mais ça ne passe pas à l'échelle sur des trucs critiques, sur l'infrastructure, sur la défense, c'est impossible.
Tu vois, il y a une sorte de méfiance.
En fait, c'est ce que je dis souvent.
Il faut pas considérer que c'est un humain.
Et souvent, les gens pensent que c'est un junior.
à juste titre, dans le sens où il faut tout relire.
Par contre, c'est quand même un junior qui a dû la totalité des thèses.
Donc en fait, il est quand même très intelligent, tu vois, ton junior.
En fait, le truc, c'est qu'il faut que tu encadres ça par énormément de tests.
Le truc, c'est que tout le monde regarde les tokens et se dit, mais ça va être hyper cher.
En fait, ta génération de code, qui permet de générer le code, va te coûter ça et tu vas l'encadrer par tout ça, token brûlé.
pour tester que ce que tu fais est bon, que ton code soit à maintenant, mais tu te t'embares les stères.
Tu ne vas plus jamais le récrire.
En fait, tu ne vas plus jamais repasser dans ton code.
Ce qui va être ton code, c'est tes specs, ton archi, ta construction, ton test, ton
environnement.
Moi je te suis jusque là, mais là ça me, je sais pas, ça me...
Ah non, mais moi en tant que développeur, ça m'a dépoilé aussi.
J'ai mis des mois à accepter cette réalité.
Donc d'après toi les limites qu'il peut y avoir aujourd'hui qui servent un peu le narratif aussi que globalement les lm ça prend de la merde c'est plutôt des quelque chose de passager qui est lié au fait que les gens ont pas créé une bonne architecture il faut il faut créer l'architecture au dessus en fait c'est
c'est quoi les règles qu'on te dit depuis des années on te dit
Il faut avoir un système de langage avec des types parce que ça t'empêchera à la compilation de faire n'importe quoi.
Bon bah Rost type très fort.
Mais c'est un exemple, mais il y en a d'autres.
Mais ensuite, bah si tu fais des tests, tu sais si ton code dérive ou si il fait ce qu'il veut.
Test Driven Development pour le coup.
Bah en fait, ce qu'on vient d'expliquer, tu réduis ta boucle de feedback, tu vas plus vite.
Si t'es capable de faire de la test qualité, etc., pareil, tu vas savoir si ça dérive ou pas.
Et en fait, tout ça, c'est des bonnes pratiques.
C'est juste que tu les fais exécuter beaucoup en automatique plutôt de les exécuter toi-même.
Mais tu peux faire autre chose.
Tu dis, je vais faire des pen tests et des audits sur les bases de code en sécurité de façon standard.
– De manière automatique aussi.
– Et nous, c'est ce qu'on fait.
Tout commis te rentre en chez nous aujourd'hui, se tape du pen test.
Donc le Pentes détecte tout.
Je t'ai dit juste que si le Pentes de Claude détecte pas un truc, il y a peu de chance pour que le Pentes du Claude du mec d'à côté, quand il va essayer de te pénétrer, va rentrer.
Du coup, tu viens de diminuer encore une fois ton risque.
Du coup, tant que tu y es, tu vas lancer Gémini, puis tu vas lancer Grog, puis tu vas lancer un peu tout le monde sur toi-même en permanence à essayer de te tabasser.
Depuis qu'on a
lancé l'IA en free range sur nos installs.
On a trouvé plein de failles que, manifestement, personne n'a jamais exploité parce que c'est pas dans les logs, donc après y'aurie c'est bon.
Mais qui était là, parce qu'on peut pas penser à tout.
Et l'IA, c'est juste toi, en un peu plus con, mais qui travaille 100 000 ans d'affilée.
Et donc, évidemment que le truc fait des trucs que tu pouvais pas faire, parce qu'il y a des tests en peine test, tu les fais pas en disant genre, c'est trop long.
Et c'est pour ça que moi ce que j'ai annoncé dans les équipes, tu vois, je crois vraiment en ce modèle.
Ce que j'ai dit aux équipes, c'est que notre objectif de l'année, je sais pas si on va y arriver, c'est de dire qu'en 2026 chez Clévent, on ne fera plus tourner que du code produit en 2026.
C'est à dire qu'on aura buté tout le legacy.
Le code qui a écrit depuis 15 ans, moi j'ai annoncé à tout le monde que notre objectif était tout décommissionné et que là on est en train de le faire.
Alors après je sais pas encore si ce sera un succès, ça augure bien pour l'instant, mais notre objectif c'est qu'il n'y ait plus de légacies chez nous.
Et pour autant, on peut toujours être fier de notre code.
C'est toujours nos architectures, notre truc.
Surtout qu'il y a des morceaux de code, c'est de la traduction directe et de l'encadrement.
En fait, c'est
vrai de la filiation.
Si tu réécrites ton système dans un autre langage, toute la conception, le code initial existe d'une certaine manière encore.
Et puis, tu peux faire des trucs que tu pouvais pas
faire avant.
Tu peux faire des trucs du genre.
On m'a dit que telle librairie était plus pertinente, plus performante, plus sécuritaire.
Là où avant, ta migration d'hybréry, c'est au minimum deux semaines en lise, plus il y a un moment où ça va déconner ou tu ne sais pas trop pourquoi.
Donc tu essayes même pas.
Là, tu peux dire LLM, écoute, test.
Juste pour voir.
Implément tout de A à Z et on se retrouve
demain.
Et donne-moi un audit de perf de trucs.
Et ton agent te sort un audit de perf et tu dis bien on vient de faire x3 quoi.
Et ça, ça c'est extraordinaire.
Ça c'est un bon point qui est un peu différent de tout ce qu'on a dit.
C'est le côté proof of concept.
Si c'est pas important pour toi d'avoir du code qui est vraiment qualitatif, qui part vraiment en production, eh ben le gain est encore plus décuplé.
Je trouve il y a un peu ce truc de...
Vas-y, fais le poc.
Pourquoi tu penses du coup qu'on reboucle un peu avec le début de la déconversation, mais la titre personnelle aussi dans les métiers ?
Alors je connais pas tous les métiers, donc je sais pas, mais la titre personnelle, en regardant autour de moi, tous les gens que je connais me disent, mon métier a changé, je suis dans le tertiaire, je serai de beaucoup de documents, etc. Evidemment, je suis 3 fois plus productif, limite j'ai pas trop envie d'en parler au manager parce que pour l'instant,
Je préfère tirer les recettes de connaitre ChatGPT alors que mes collègues ne le connaissent pas.
Et même dans le développement, c'est évident qu'il y a des gains de productivité.
Alors après, pour faire l'avocat du diable, j'ai quand même l'impression qu'il y a des zones où tu as des gains énormes et d'autres moindres.
Donc par exemple, je pense que quand tu fais vraiment, tu es à l'état de l'état de l'art sur un tout petit bout de ta R&D ou à peu de choses qui existent déjà,
Je pense que tu peux avoir des gains de 1,5 ou des choses comme ça, ce qui sont déjà
géniales.
Il y a des
autres endroits où pour le coup c'est
incontestable.
Tu peux le bencher.
Par exemple, les gens qui écrivent du carnel chez moi te disent, il y a, nous casse les couilles plus qu'autre chose, qu'en fait il a toujours l'impression d'être en US-Orland et du coup il écrit toujours du code qui ne va pas compilé carnel.
Ou alors les gens qui écrivent le réseau chez nous, ce sont réécrits, nous les... l'OS des Switch pour nous, parce que, enfin, notre VPSC, et on l'a écrit comme ça.
Ça, en fait, il n'y a pas de code disponible là-dessus.
Qui écrit des OS de Switch ?
Du coup, on est en sécurité.
Du coup on est en sécu, on est plus performants.
Du coup on tire quand même aussi quelques pour cent de marge en faisant ça.
Moi je te rappelle, j'ai un boulot d'épicier, elle a faim.
Moi j'ai pas de fond d'un épicier, je vais chercher l'argent là où il est.
J'ai besoin d'aller chercher des sous.
Donc, t'as ces trucs-là, si tu veux, qui vont, ou clairement dessus, on se galère encore n'y a, même si je pense que dans un endroit, on va pouvoir lui apprendre.
Oui, il y a des trucs qui galèrent.
Par contre, pour moi, il y a un phénomène où t'as des gens qui veulent prendre les gains sans prendre les négatifs.
Si tu t'en sers que pour coder et que tu ne mets pas tout le harnais dont j'ai parlé autour, qui est un harnais d'augmentation de qualité et de sécurité et qui te permet, en fait, de tirer réellement les bénéfices,
Bah là, en fait, oui, c'est la foire.
Parce que, en fait, ce que tu fais, c'est que tu produis du code que tu comprends pas dans un modèle que tu comprends pas.
Et après, tu essaies de le rattraper en faisant tes tests.
Et ça, ça va merder.
Est-ce que tu penses que c'est ça qui explique qu'il y a beaucoup d'entreprises qui expliquent qu'elles n'ont pas de bons résultats, que l'IA, ça leur a pas
servi à grand chose ?
Oui, pour moi, c'est ça.
Parce qu'en fait, si tu veux, la dépense dans le code, c'est ça, comparé à la dépense de tout ce qu'il faut faire,
pour rendre l'IA pertinente et donc il faut vraiment comprendre qu'on va complètement changer notre façon de bosser tous parce qu'on va être complètement assisté dans ce truc là.
Mon dernier point pour conclure notre conversation
qui concerne aussi ton dernier passage ici.
Est-ce que toi de ton point de vue
Il y a justement dans les compétitions qu'on considère perdues d'avance, donc dans le numérique, la souveraineté numérique française, le fait qu'on ait des acteurs ou un état qui soit hyper dépendant des solutions américaines, ou le fait qu'on ait peu d'eux dans les top 15 des boîtes de tech mondial, très peu de projets européens globalement.
Est-ce que tu penses que ce statu quo que tu nous avais présenté la dernière fois que tu étais venu, il peut être chamboulé ?
par ce qu'il y a en train de se produire au niveau de l'IA en
gros.
Oui, et pour deux raisons.
En fait, il se passe deux choses parallèlement.
Le problème, c'est que le marché du digital a toujours été compris comme étant un truc de Jones un peu sympa.
Mais bon, parlons des vrais trucs, faire des voitures.
Enfin, l'éternel problème de la politique européenne où, à la fin, on te dit combien on fait de vente de Voswagon et c'est gentil avec ton serveur, mais les Voswagon.
Le marché de l'IA,
Il fait un truc, c'est que d'un seul coup tout le monde se retrouve face à un fantasme sci-fi de Jarvis, de la vraie intelligence artificielle, et là se rend compte que tout le marché va changer.
Et donc une première angoisse qui génère là-dedans de se dire, peut-être qu'il faut qu'on s'en occupe là tout de suite et que ce marché-là va être énorme et important.
Et donc, le sujet de la digitalisation du monde remonte un peu dans les priorités des décideurs, notamment à l'Europe.
Pour être franc en franc, je trouve qu'on n'y est pas assez, mais dans les grands groupes privés, par exemple, c'est ça.
Comme ça apparaît au même moment que l'ami d'Hommel Trump à la Maison Blanche a rendu tout le monde hystérique.
Le mec a une notion du partenariat qui lui est propre.
D'un seul coup, les gens se font rendu compte qu'en fait, notre lien aux États-Unis
était vachement moins solide que ce qu'on croyait et donc à ce moment là ça va générer immédiatement des gens qui se disent attend où est ce qu'on habite pourquoi et dans quel sens et du coup ça ça remet en cause des choses et le coup du logiciel drop d'un seul coup ça veut dire que la loi du retour à accélérer du progrès le truc de record sale que je cite régulièrement fait qu'en fait reproduire certaines choses va coûter beaucoup moins cher
Donc ça permet de faire des progrès technologiques monstrueux en très peu de temps parce qu'on a ces outils-là et il suffit d'être malin et intelligent dans la façon de l'architecturer.
Donc si tu veux ça casse quelque part ce statut-cola, après il n'empêche qu'on n'a pas toujours la longue chaîne industrielle qui faisait la IT.
Par contre, il y a des pouboucs qu'on peut copier.
Regarde ce qu'on fait les Chinois.
Et donc on va pouvoir avoir des modèles apprenant des choses, et donc la bulle de l'IA avec des gens qui seront très forts parce qu'ils ont les modèles, c'est pas sûr.
On regarde un Kimi MK2 aujourd'hui face à un Claude.
C'est pas le Claude de la dernière génération.
Il est quand même pas très loin.
Ce
que tu veux dire, c'est qu'à la fois sur la dépendance logicielle historique, les cartes peuvent être rebattues parce qu'on va peut-être pouvoir
recréer des versions européennes à moindre frais parce que le logiciel est moins cher.
Et même sur les modèles en soi, l'avance qui existe potentiellement dans des modèles américains, on sera peut-être un peu derrière mais jamais très loin notamment parce qu'on peut les distiller.
Si on se donne les moyens, aujourd'hui notre plus grand problème c'est qu'il faut qu'on décide de se donner les moyens.
Et que, comme d'habitude, on fasse diriger l'opération par des techs.
Si tu ne demandes pas des techs de diriger l'opération et des pirates et des hackers dans l'âme, ça ne va pas le faire.
Par contre, aujourd'hui, on peut rebattre les cartes.
Et pour la première fois, on a l'oreille.
Qu'est-ce qui a changé depuis que tu es venu nous parler ?
Parce que quand tu es venu nous parler, globalement, si on résume, tu nous as dit qu'il n'y a pas trop d'oreilles.
Est-ce que des choses ont changé
?
Il y a plusieurs choses qui ont changé.
Il y a certaines institutions qui ont pris conscience du problème, notamment l'Europe.
L'Europe dépense un premier milliard annuel en cloud public.
Et ils ont dit, on a décidé qu'on allait progressivement re-souveraniser ça.
Alors la première chose sur laquelle il faut être clair, personne en Europe est capable de prendre une commande d'un premier milliard en cloud.
Donc ils ont fait un appel d'offre à 180 millions, où ils ont dit, on veut du cloud souverain.
Et on va définir ce qui est souverain, via un truc qu'ils ont appelé le Sovereignty Framework, qui est un truc relativement long, compliqué et fonctionnel, qui permet de noter si on est souverain, pas souverain, etc. Et on fait un appel d'offre.
Appell d'offre qui a été remporté par plusieurs contestantes.
L'un des consortiums qui a remporté l'appell d'offre, c'est une alliance entre OVH, la poste luxembourgeoise et Clever Cloud.
Skylway a gagné un autre truc, Stack It, l'autre, et un dernier qui est un paquet de...
pseudo-pôtes bossant autour de Google, plus mistral avec des trucs qu'on gagnait, mais qu'on gagnait ce qu'on appelle SIL 2, parce que tu peux être SIL 3 ou SIL 2, SIL 3, t'es sécurisé, t'es souverain, SIL 2, tu n'es pas souverain, mais évidemment, c'est Google.
Donc voilà.
Mais donc ça, tu vois, par exemple, ils ont fait un gros appel d'offre et ils ont fait gagner des restaurants.
Et ils voulaient rentrer.
Le truc de vous, ça.
C'est dingue.
C'est dingue.
Et en face, il y avait des grands cloud publics.
Il y avait tout le monde à compétiter à ce truc-là.
Parce que de si mes souvenirs sont bons, normalement les appels d'offre étaient plutôt écrits.
Non parce qu'ils ont écrit
le framework de souveraineté pour nous donner une chance.
Et du coup ils nous ont donné une vraie chance dans la notation.
C'est à dire que les lobbies sont moins d'influence.
C'est compliqué face aux conneries de Donald Trump d'avoir l'air sérieux.
Et en plus sur l'argent, ça marche.
En fait, les conférences économiques que je donne sur l'argent finissent par rentrer sur...
En fait, on a un problème de fric, mine de rien.
Donc ça, c'est un vrai sujet.
Il y a fait peur aussi.
Tant que c'était l'informatique, ça allait là d'un seul coup, tout le monde change son travail avec ChatGPT.
Le jour où tu commences à utiliser ChatGPT, quel que soit ton boulot, ton boulot change.
Donc il y a des vrais avancés.
En France, on a englué dans un espèce de loi de budget, gestion d'air-trait, présidentie d'avenir, qui fait qu'on a du mal à faire progresser les sujets politiques autour de la souveraineté.
Mais tu vois, il y a des débats que j'ai aujourd'hui, que je ne pensais pas avoir.
Tu vois, par exemple, on a écrit un truc qui s'appelle la clause de souveraineté finale.
C'est une clause que je mets dans mes gros contrats avec soit des Etats, soit des trucs comme l'Europe, etc. où je dis aujourd'hui que l'evercloid est européen.
je vais synchroniser la totalité de longues codes source, mes procédures, tout le fonctionnement, avec un tiers de confiance, l'UNC, l'ENISA, whatever.
Et si Clair Claude change de contrôle en termes de loi extraterritoriale, en clair si je deviens américain, chinois, russe, whatever, alors mon client souverain gagne automatiquement une licence illimité de Clair Claude, ma clause de non-solicitation de personnel tombe,
Vous avez le droit de venir taper mes salariés et vous repartez avec le code et les salariés si vous voulez.
Autrement dit, la boîte ne vaut plus rien.
Pourquoi est-ce que j'ai fait ça ?
Parce que vous pouvez vous dire que de toute façon Quentin ne voulait pas vendre aux Etats-Unis.
Oui mais là, si je prends des investisseurs, mes investisseurs peuvent pas être des gens qui veulent que je conquier le marché européen pour ensuite me larguer aux Américains.
C'est impossible puisque la boîte n'a plus aucune valeur au moment où je fais ça.
Donc je me suis volontairement assis sur un paquet de dynamite et j'ai le
briquet parce
qu'il faut faire avancer le truc.
Et ça, tu vois, cette clause-là, on réfléchit à la faire pénétrer dans le système de notation soit de l'indice de résilience numérique, soit dans le sovereignty.
Il est déjà intégré dans le sovereignty framework de la Commission, commettant un truc qui te permet de prouver que t'es réellement souverain.
Et ça, tu vois, ça a des transformations, c'est-à-dire que tout le secteur Vici me regarde, genre, mais tu vas pas réellement mettre ça dans les contrats.
Ah si, gros.
Parce que du coup, tu vendras plus les boîtes aux américains.
Mais ce qui veut dire qu'on dit aussi aux grands-gaux français, si on peut plus vendre des boîtes aux américains, il faut que vous les achetiez, les mecs.
On pourrait te rétorquer qu'en fait, qui ne dit pas d'achat américain, ne dit pas de liquidité et donc les investisseurs ils veulent plus mètre d'argent parce qu'il faut qu'ils gagnent leur argent.
Donc on n'a pas de beau exit dans la French Tech.
On peut aussi dire, mais du coup on va en aller boitant en bourse.
Prends des boîtes comme Wallix.
Cette année, ils sont fait 274% sur leur action.
Tu vois, c'est le président d'Exatrust, Walix, qui fait des systèmes d'identité.
Des boîtes comme 2 CRSI qui construit des serveurs en France, qui est un des seuls constructeurs en France avec Bulle, 2 CRSI, je crois qu'ils ont fait 2000% de croissance en bourse.
En fait, nos petites PME de croissance qui étaient déjà boursières avant cette ère de souveraineté ont fait des performances boursières monstrueuses.
Donc ça veut dire qu'en fait, on pourrait imaginer que si les grands groupes veulent pas suivre,
c'est pas grave.
On emmène nos boîtes dans un modèle de financement où en fait on fait des exites boursiels.
C'est pas un problème.
Donc c'est assez structurant ce qui est en train de se passer.
C'est dur.
Il faut continuer à casser les couilles de vos élus et de vos députés et de vos sénateurs et aller casser les couilles des gens en leur disant le digital est un marché important si on ne fait pas les choses dans le bon ordre on aura un problème.
Mais là on vit un moment où alors on a une révolution géopolitique, financière, technologique
Enfin c'est hyper excitant et si vous vous emmerdez tous les jours dans votre métier, changez taf parce que là, on s'amuse.
Ah grand merci Quentin, c'était trop
intéressant.
Et en te re-accueil avec plaisir de façon, ça change tellement que de deux ans, tout aura changé.
On peut faire ça tous les deux ans.
Si vous voulez creuser le sujet, je vous recommande cet épisode avec l'un des rares ingénieurs à qui Anthropique a donné un accès débridé à son IA Mythos.
Il raconte comment ça a bouleversé son entreprise et pourquoi peut-être on pourrait en réalité prendre de l'avance sur les cyber-attaquants.
c'est juste ici.