Usine logicielle 100% AI : Qui réveille-t-on quand l'usine prend feu ?

Bruno — Au Japon, dans certaines usines Fanuc, il y a des robots qui fabriquent des robots. Pas de lumière, pas de chauffage et parfois un mois entier sans qu'un seul humain ne passe sur la ligne de montage. Les japonais appellent ça une usine qui tourne dans le noir. Dans le logiciel, on y est presque. Des agents qui codent la nuit pendant que les laptops sont fermés. On a 100 sessions en parallèle, on a des PR qui pleuvent et qui s'ouvrent toutes seules au petit matin. Mais alors, quelles étapes du cycle de dev peut-on vraiment confier à une machine ? Faut-il encore qu'un humain lise l'EPR ? Et surtout, quand l'usine tourne dans le noir, qui faut-il réveiller la nuit quand elle prend feu ? Pour répondre à ces questions d'automatisation, je ne reçois pas Willy Wonka, mais il s'y connaît en usine. Nikolai, bonjour.

Nikolay — Bonjour.

Bruno — Alors Nikolai, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Nikolay — Je suis Nicolas Irodionov, je suis ingénieur et entrepreneur. Il y a maintenant 15 ans, j'ai monté une première boîte qui s'appelait Streamroot, qui faisait du streaming vidéo assisté par Pire2Pierre. Donc en gros, imagine un BitTorrent, mais qui fonctionne pour du contenu légal, que j'ai depuis vendu et laissé. Et aujourd'hui, depuis maintenant un an, un an et demi, j'ai créé une nouvelle boîte qui s'appelle Alpic, qui a pour mission d'aider les boîtes à devenir agent ready, c'est-à-dire à créer des interfaces spécifiques pour les agents, pour que les agents puissent les utiliser.

Bruno — Ok. Et donc l'idée là sur Alpic, c'est pas forcément de faire en sorte que toutes les équipes de dev utilisent de l'IA dans la génération de code, c'est de faire en sorte que, toute entreprise qui a une application ou un service soit en gros utilisable via un MCP ou un protocole équivalent par d'autres agents, c'est ça ?

Nikolay — C'est ça, oui. En gros, on va avoir des boîtes B2B et B2C, et on, peut construire leur serveur MCP ou les applications MCP. Et ensuite, on a un cloud d'hébergement qui permet d'hoster ton serveur MCP et d'avoir des analytics, du testing, de la QA, etc. Et en plus de ça, quand même, j'en parle parce que c'est open source, on a créé un framework qui s'appelle Skybridge, qui est le premier framework, open source pour faire des applications MCP.

Bruno — Ok, canon. On mettra bien évidemment quelques en descriptions si les gens veulent aller tester ce framework. On a une population de gens qui nous écoutent qui aiment bien tester de nouveaux trucs, donc il se peut que ça donne des envies. Et donc, cette création d'applications et de services MCP, aujourd'hui, vous avez une équipe de dev qui dev tout ça ou, de ce que j'ai compris, tu as quand même une usine logiciel qui est pas mal automatisé je crois c'est ça.

Nikolay — Alors on a commencé à la main il y a un an un an et demi justement et, depuis maintenant 4-5 mois. On a essayé de mettre en place une software factory, donc une usine logicielle, pour faire un maximum de code automatiquement à la place de nos développeurs. Alors, usine logicielle ça peut tout et rien dire, c'est un mot un peu idéaliste. En soi, une usine logicielle c'est juste à, Ton cycle de développement, donc ta SDLC, qui normalement est une usine humaine un peu manuelle, où tu as ta team produit qui va aller chercher les idées depuis tes clients ou depuis, je ne sais pas, la team fondatrice. Ils vont ensuite les transformer en PRD en, requirement produit, ils vont faire les mock-up le design etc etc et ils vont passer toutes ces specs à la team de développement qui normalement va les développer, à la main ou à l'aide de l'IA et enfin une fois que c'est développé et mis en prod t'as, un cycle la boucle qui se boucle Car tu vas avoir les clients Ou même tes alertes de prod Qui vont te donner de nouvelles idées Ou de nouvelles choses à faire. Et du coup, quand nous, on parle d'usine logicielle IA. Notre but, notre process a été de regarder chaque étape, chaque sous-étape dans toutes ces parties et voir quelles sont les étapes qu'on peut automatiser, soit complètement avec des agents qui produisent du coup, par exemple, soit le PRD, soit le code, soit qu'ils fassent la QA, soit qu'ils fassent la review de code. Il y a plein d'étapes, je ne vais peut-être pas toutes citer, que je pense que les, écouteurs, les auditeurs, pardon, anglicisme, connaissent. Et donc, on a mis une personne dont le rôle était de passer chaque étape un peu au crible et voir si on peut l'automatiser.

Bruno — Donc il y avait vraiment une volonté d'emblée de se dire on va essayer de tout automatiser ou ça s'est fait petit à petit et puis à un moment tu t'es dit bah en fait on en a déjà fait pas mal donc on peut peut-être s'intéresser aux autres parties de la boucle.

Nikolay — Alors... En fait, on a vu pas mal d'articles, de podcasts aussi d'ailleurs, de grosses boîtes dans la Silicon Valley qui ont dit, nous, on a réussi à le faire. En tout cas, on partit, on avait 70 ou 80% de nos PR qui sont maintenant faites end-to-end par de l'IA. Et du coup, on s'est dit, si eux peuvent le faire, pourquoi pas nous ? Donc l'objectif à long terme, la North Star qu'on s'est mise, c'est en effet automatiser 100% du process, tout en sachant qu'on ne va pas y arriver, parce que je pense que c'est idyllique. Et une fois qu'on a dit ça, on a regardé les différentes étapes et on s'est dit quelles sont les parties qui sont d'une part les plus faciles, qui semblent les plus faciles à automatiser, et quelles sont les étapes qui ont le plus d'impact ? Hum et donc, on a on a commencé par deux côtés on a commencé d'une part par la partie produit donc l'écriture de PRD de spec de tout ce qui est design, et de l'autre côté bien sûr par la partie un peu implémentation donc une fois que tu as tes spec, écrire le code faire les reviews faire la QA mettre en prod etc voilà.

Bruno — Donc en gros parce que effectivement on est ok que c'est un cercle parce que, c'est un cycle mais c'est un cercle qu'on représente aussi parfois de manière linéaire on considère que tu as une idée de base jusqu'à une mise en prod, et donc en fait de ce que je comprends vous avez commencé par le début de cette ligne donc le produit puis l'implémentation pour la descente petit à petit ou est-ce qu'il y a un moment où vous êtes revenu en fin de chaîne avant de vous retrouver au milieu ou, est-ce que ça s'est fait naturellement ou est-ce que vous vous êtes dit on va commencer par le haut pour petit à petit aller vers la fin ?

Nikolay — En fait, déjà, sur la partie code, tout ce qui touche au code, on s'est vite rendu compte qu'il y avait un problème, une problématique qui n'était pas simple à résoudre, qui était que tes agents, si tu veux qu'ils soient vraiment autonomes, il faut qu'ils aient leur propre environnement de devs. Il faut qu'il puisse avoir, accès au même contexte que n'importe quel développeur sur sa propre machine, sur son MacBook. Et en fait, ça, ce n'est pas si facile parce que tu as souvent un staging que tu peux peut-être répliquer, mais tu ne veux pas que ton agent IA ou que ton dev bosse sur ton staging. ça ne marche pas. Et donc la première vraie étape en fait ça a été de travailler sur cette partie là de notre SDLC pour que chaque dev ait son propre environnement déjà une chose qu'on n'avait pas à 100%, parce qu'on n'avait pas un compte Stripe pour chaque développer, on n'avait pas des comptes des environnements Amazon pour chaque développer, c'est quand même un truc qui est, assez pénible à mettre en place mais qui a beaucoup plus d'intérêt quand t'as pas d'e-développeur mais quand t'as 100 ou 1000 agents qui chacun peuvent travailler de son côté, Et donc, on a fait ce système-là avec, en gros, une architecture assez classique. On a des sandbox, un fournisseur de sandbox, sur lequel on a fait en sorte d'installer par script, pour le coup, un événement de dev de A à Z. Et donc, ça, c'est ce qui a pris quasiment le plus de temps, en tout cas au début. Mais c'est ce qui a aussi permis vraiment les expérimentations avec ce qu'on appelle nos agents autonomes.

Bruno — Vous aviez combien de devs dans l'équipe quand vous avez commencé ? Vous en avez combien aujourd'hui ?

Nikolay — On est encore tout petit, on a commencé il y a un an qui est je pense une chance pour le coup pour nous, On a 5 devs et on avait toujours 5 devs On avait 5 devs, on a toujours 5 devs.

Bruno — Cet ajout quand même de sandbox dont on est forcément obligé de se dire, il y a peut-être quand même un coût qui est associé. Parce que ce que je comprends, c'est-à-dire que chaque agent que va lancer un de vos développeurs ou développeuses va générer une nouvelle sandbox, ce qui est forcément un coût quelque part.

Nikolay — Bien sûr.

Bruno — Est-ce que vous mettez des limites ? C'est quoi le coût que vous retrouvez sur ces nouvelles sandbox ?

Nikolay — Alors... Ce qui est cool, c'est qu'on utilise les nouvelles générations de soundbox qui sont éphémères et qui sont faites pour les agents. Ce n'est pas des VM que tu lances sur AWS. C'est des soundbox qui peuvent vivre 10 minutes et qui sont facturés à la seconde. Et donc finalement, je n'ai pas le prix exact, mais je pense qu'on doit dépenser 10-20 dollars par jour en soundbox, alors qu'on lance des dizaines d'agents.

Bruno — Par développeur et développeuse ou au total ?

Nikolay — Non, en tout. En tout parce qu'en fait, une sandbox, un agent n'appartient à personne.

Bruno — Oui, donc ce qui au final est assez marginal. Pour une équipe de 5 personnes, c'est assez invisible.

Nikolay — En tout cas, ce coût-là, alors peut-être qu'on n'a pas encore ce qu'il est assez, mais il est relativement négligeable, notamment aussi par rapport au coût de token qu'ensuite l'agent va dépenser, qui a un coût de token qui de toute façon sera dépensé aussi sur la machine du développeur.

Bruno — Cette volonté de tout automatiser alors si tu peux nous répondre en toute transparence ça peut être très bien, mais parce qu'en fait on peut imaginer plein de raisons pour lesquelles on a envie de tout automatiser ça peut être parce que t'as envie d'aller plus vite parce que t'as envie d'être moins cher parce que t'as envie de consacrer tes ressources à d'autres choses ça peut être parce que t'as envie de réduire la taille de tes équipes parce que du coup tu peux faire plus avec moins, c'est une forme d'externalisation ça a été quoi un peu les les moteurs pour vous en vous disant en fait il faut qu'on y arrive à ce pas des questions qualité aussi ce que du coup tu sais que tes agents ils peuvent écrire du code de manière un peu identique à chaque fois c'est quoi un peu les drivers pour vous ouais alors.

Nikolay — Nous, comme je disais, on est une start-up en plus dans l'IA. Donc, notre premier, besoin et première motivation, c'était d'apprendre et de voir jusqu'où on peut aller. Comme je te disais, on a vu des boîtes, on a vu OpenAI dire qu'ils ont automatisé plein de choses. On bosse, nous, avec OpenAI assez souvent. Et donc, on s'est dit. Si on n'apprend pas maintenant, on va avoir du retard avec d'autres personnes, d'autres boîtes qui sont potentiellement compétitrices, qui vont aller plus vite. Et donc, oui, le but, bien sûr, c'est de produire plus avec, pour le coup, chez nous, le même nombre de personnes. Et donc, d'accélérer la delivery end-to-end de tes features, c'est sûr. Mais c'était surtout de comprendre comment ça marche comprendre aussi les limites, d'une software factory et s'adapter parce que, même s'il y a des limites aujourd'hui je suis moi convaincu que dans 6 mois ou dans 12 mois, il y a beaucoup de ces limites qui vont disparaître, et du coup former ta team développeur, au futur ça a aussi un énorme un énorme avantage et je pense que c'est un besoin pour pas rester pour pas être dépassé par les autres.

Bruno — J'imagine aussi qu'avant de te lancer sur un projet aussi conséquent avec un impact sur le métier, sur vos équipes sur ce que vous livrez à vos clients en arrière, tu te mets j'imagine à un certain nombre de métriques pour mesurer un peu l'évolution de tout ça ça a été quoi pour vous les indicateurs pour vous dire là ça est successful ou au contraire, il faut qu'on roll back.

Nikolay — Alors, ça a été assez simple. Bien sûr, on s'est dit, on va regarder le temps, que tu mets à délivrer ta feature en comptant la partie produit, design, planification, spec, etc. Ça, c'était une des métriques. La deuxième, c'était bien sûr l'utilisation de, ces agents parce qu'un des autres buts dont je n'ai peut-être pas parlé, c'était d'avoir des agents accessibles à tout le monde dans la team pas que les développeurs c'est une software factory certes mais on voulait que, la team commerciale si elle a un problème client elle puisse aussi l'utiliser pour peut-être débuguer un problème ou même répondre parfois à un client qui demande quelque chose de technique sur l'architecture de comment notre infra fonctionne par exemple, donc l'utilisation. Et le fait que ça soit accessible à tous c'était super important, ensuite bien sûr le nombre de tokens utilisés et si possible le fait que ce nombre de tokens soit plus petit que le nombre de tokens utilisé par la team dev, s'il code chacun de son côté, et est-ce que j'en oublie non, c'est pas vraiment une métrique mais la qualité de notre code et le fait qu'on n'ait pas plus de problèmes, qu'on n'utilise pas de bugs.

Bruno — Qu'on n'ait.

Nikolay — Pas de downtime sur notre infra aussi voilà.

Bruno — Est-ce que du coup aussi quand tu lances ce projet il y a une espèce de il y a une règle d'or au fixé en vous disant il y a certains endroits où on va laisser les êtres humains à intervenir ou est-ce qu'au contraire vous êtes parti en vous disant, la target c'est la boîte noire totale et le code, tout est fait tout seul ?

Nikolay — Alors, on aurait bien aimé, que ce soit possible de faire une boîte noire totale, mais on a quand même essayé. Mais juste plutôt pour se marrer qu'en y croyant vraiment, on a essayé bien sûr d'avoir des agents qui fassent toute la partie PRD par exemple tout seuls, ou toute l'implémentation en, boucle fermée sans humains qui interviennent. C'est assez évident que ça ne marche pas. Je pense que n'importe qui qui a essayé de hype coder un projet voit que très très vite, ça devient quand même du slope, comme on dit. Et donc, assez vite, on a vu, on s'est dit que typiquement, dans la partie PRD et spec, il fallait qu'il y ait des humains et que du coup, l'IA serait plus là en mode copilote qu'en mode agent autonome. C'est la première partie la deuxième c'est la code review. Aujourd'hui avec une très bonne spec je pense qu'un, codex, un cloud code Astra ou Opus 5.5 ils arrivent à faire du meilleur code, qu'un humain dans 90% du temps et ils arrivent à faire du code aussi assez élégant, en tout cas, qui est bien solide. Par contre, le problème, si tu n'as pas de... Si tu n'as personne qui review ton code, le problème, il est plutôt dans l'ownership, en fait. Comme tu disais en intro, qu'est-ce qui se passe si tu as un problème avec ton infra à 3h du mat et que des agents ont écrit à toutes tes paires ? Et qu'ils n'arrivent pas à le résoudre en fait. Si tu leur demandes, parce que tu vas leur demander bien sûr, et s'ils n'ont pas de solution, qui est-ce que tu appelles derrière ? Est-ce que c'est le CTO ? Quel est le développeur, que tu vas appeler ? Vu qu'il n'y a personne qui a écrit le code. Nous, on a pris le parti pris d'avoir un dev qui est responsable d'une PR, même si elle est codée par un agent, pour qu'il y ait un ownership sur le code et sur chaque paire qui est introduite dans ta code base.

Bruno — Avant de creuser le sujet de l'ownership, qui est un sujet hyper important, tu nous as évoqué que vous avez fait des expérimentations et que ça a dégénéré assez vite quand tu laisses l'IA toute seule gérer toute la boucle. Ma question, ce serait à quelle vitesse, au bout de combien de temps ça a dégénéré, et sur quels critères vous avez vu que c'est parti en caouette et qu'il fallait l'arrêter ?

Nikolay — Alors, pareil, je pense qu'il y a deux parties. Sur la partie produit, on l'a vu très, très vite. On a essayé d'avoir des skills pour les agents qui disent quelle est la structure d'un PRD, quels sont les PRD d'exemple. On en avait une dizaine, je pense, qui étaient très bien écrits à la main par nous, qui montraient comment faire. Et même avec ça, on voyait que l'agent produisait un peu, pas n'importe quoi parce que c'est quand même sensé ce qu'il disait mais en fait quand tu crées un PRD quand tu t'écris, l'essence d'une feature chaque mot va compter dans ce que tu écris quand tu es produit en tout cas, et très vite on a vu qu'un agent laissé seul, il n'arrivait pas à faire ça et, les humains qui relisaient le PRD, dès qu'ils voyaient que c'était un peu trop slop ils arrêtaient de lire et donc ça ne marchait plus. Donc là c'est sur la partie produit, Sur la partie dev, je dirais que ça dépend de à quel point tu le laisses seul ou à quel point tu lui donnes des contraintes. Moi qui vaip code beaucoup plus que code maintenant, en une journée, j'ai que du slope. Parce qu'en fait, tu relis pas le code. Si tu donnes un peu plus de contraintes, il peut suivre un peu. Mais tu sais que c'est pas du code maintenable en fait.

Bruno — Tu

Nikolay — Sais que c'est du code que tu vas devoir jeter à la poubelle assez vite.

Bruno — Sur le sujet de l'ownership que t'as évoqué tout à l'heure qui est un sujet hyper important, t'évoques la notion de code review si t'as chaque développeur et développeuse qui est capable de lancer plusieurs agents qui vont générer plusieurs PR par jour, dans quelle mesure, comment tu fais pour qu'un humain soit capable d'ingérer tout ça parce que d'autant qu'il y a des tailles de PR qui augmentent, il y a un nombre de PR qui augmente comment est-ce que tu fais pour qu'un humain soit capable, de vraiment avoir cet ownership et pas juste commencer à valider sans vraiment regarder et du coup à perdre de manière indirecte cet ownership.

Nikolay — Attends juste deux.

Bruno — Secondes Vas-y vas-y.

Nikolay — Donc comment on fait pour pour review autant de paires ? Le problème, comme je te disais, c'est que tu ne peux pas faire en sorte, de ne pas les lire. La meilleure chose que tu puisses faire, c'est de rajouter des checks, ce que nous, on appelle des quality gates. Donc, en gros, des étapes où automatiquement, ou grâce à un agent, tu vas vérifier, si le code produit est assez bon faut pas essayer de tout faire par un agent, le premier truc c'est de faire du linking de code et ça tu peux déjà le faire beaucoup de choses avec ça, et après ça en fait nous ce qu'on a fait c'est qu'on avait des, conventions de code qu'on a écrites, à respecter et qu'on donne à des agents qui vont review le code avant l'humain, pour faciliter pour avoir une boucle de feedback déjà entre le reviewer et l'agent qui écrit le code jusqu'à ce que ça soit bon et du coup ça augmente, la confiance que l'humain va avoir dans le code écrit par l'agent.

Bruno — Mais en fait je comprends effectivement l'intérêt d'avoir un ensemble de systèmes, déterministes ou non déterministes qui vont relire ton code avant pour essayer, de filtrer un ensemble de problèmes et qu'au final t'es juste une question de validation mais au final ça impacte pas le volume, d'éléments que tu dois valider et relire chaque jour c'est à dire que si effectivement, t'es sûr que ta PR quand elle t'arrive elle a été déjà relue et les problèmes de base sont partis c'est très bien mais t'as quand même ta PR à relire tu peux pas l'envoyer en prod de manière automatique.

Nikolay — Alors, ça dépend. Nous, on a fait quand même un changement assez gros, je pense. C'est qu'en fait, quand on parle de PR Review, je pense que les gens parlent souvent de deux choses différentes. Si l'agent si c'est un agent qui a produit ta PR, est-ce que c'est une personne qui est en fait responsable de l'agent qui doit la revoir ou est-ce que c'est aussi ton équipe ? Parce que normalement vu que toi t'es responsable de ta PR, dans un process classique, aujourd'hui t'as une autre personne de ta team qui doit revoir cette PR, et nous en fait c'est cette deuxième étape là qu'on a enlevé parce que souvent c'est d'ailleurs l'étape qui prend plus de temps parce que le dev il a fait ses 10 d'IPR, et parfois il peut attendre 3 jours, une semaine avant que quelqu'un d'autre soit dispo en fait pour la relire, et nous on a voulu enlever cette partie là, parce qu'on se disait que si l'agent est considéré comme un dev on va dire, qu'il y a déjà plein de checks qui sont faits quand ça arrive à l'humain qui en est responsable, à l'humain, s'il a tout le contexte et qu'il est assez bon rivieur, il n'y a besoin que d'une personne qui revue ce code, même s'il n'a pas été fait par un humain. Mais pour ça, on a dû faire un gros travail sur les specs parce que dans une... Avant. Les agents de code, la peer review, la review par quelqu'un de ta team, elle servait aussi à d'une part partager la connaissance entre les devs et d'autre part à, discuter des problèmes que tu aurais vus après que tu aies fait l'implémentation de ta spec. Parce que souvent une spec, ce n'est pas suffisant pour voir les problèmes en avance. Et donc, nous, cette partie de spécifications plus détaillées, on l'a mis plutôt avant l'implémentation du code. Et donc, la discussion aussi avec la team, on l'a bougé de après la paire à avant la paire dans les specs qui sont du coup maintenant beaucoup plus détaillées qu'avant.

Bruno — Et donc, l'étape de code review, c'est-à-dire qu'aujourd'hui, quelqu'un qui va lancer un, deux ou trois agents, il va relire l'ensemble du code qui est livré par l'ensemble de ses agents, comment tu fais pour que tu gardes cette capacité à relire tout ce qui est pondu alors que t'as des agents qui vont te pondre des milliers de lignes de code chaque jour.

Nikolay — Alors pour ça j'ai pas la réponse.

Bruno — Encore.

Nikolay — Pour l'instant en effet c'est clairement un des bottlenecks c'est le bottleneck le plus gros, on arrive à s'en sortir avec 5 d'hyper mais oui c'est sûr que quand on a RASAN il faudra automatiser cet état.

Bruno — Possible.

Nikolay — Mais je pense qu'on n'y est pas encore.

Bruno — Mais là du coup aujourd'hui le volume de travail que ça représente pour ton équipe de dev est-ce que tu sens qu'il y a déjà une fatigue est-ce que tu as l'impression que du coup il y a du code qui est validé sans trop le regarder parce que j'imagine que c'est le cas, et peut-être que vous l'avez formalisé de vous dire en fait il y a certaines parties du code, qui sont moins critiques, qui sont moins graves, et donc en fait, tu as moins besoin d'aller affiner les choix d'un plème qui sont faits, alors que tu as des parties qui sont peut-être un peu plus critiques, un peu plus touchy, où là, tu dis, là, on va être vigilant, on relit bien. Est-ce qu'il y a juste comme ça que vous avez formalisé ?

Nikolay — Oui. Alors, ce qu'on a vraiment formalisé, c'est le fait de, justement, que ça soit le développeur. Donc, comme je te disais, nous, on a un développeur à son agent, et lui, il est responsable du code que l'agent produit. Et si quand il review lui-même il est pas sûr justement d'une implème il peut appeler le reste de l'équipe en disant j'ai besoin d'une review supplémentaire, sinon par contre si vraiment, la paire est simple je pense que c'est au jugement aussi du développeur de dire est-ce que je relise chaque ligne je pense qu'il n'y a personne qui relie chaque ligne dans une paire même entre deux humains je pense que c'est assez, assez idéaliste de croire que tout le monde relit toutes les PR et chaque ligne de code, chaque caractère qui est écrit, donc je pense que c'est pareil et en fait plus tu fais confiance à ton IA, moins t'as besoin aussi de relire.

Bruno — Dans le détail Ce sujet de confiance qu'effectivement quand tu mets en place cette usine logicielle t'as besoin de construire ton alain donc tout de ce que je comprends en vous aujourd'hui c'est surtout sur la partie produit et implémentation on parlera peut-être après de la partie CI-CD, pour la suite de la chaîne mais, t'as besoin effectivement d'avoir confiance dans ton harnais, t'as parlé de tes lintern un ensemble d'outils que tu peux avoir qui soient gentils ou non euh... Ma question m'a échappé pendant que j'étais en train de la dire. Comment est-ce que tu fais pour, développer cette confiance et donc créer un outil qui soit suffisamment structuré ? Parce que tu évoquais tout à l'heure, vous avez beaucoup vu, et on le voit aussi, des grosses boîtes comme OpenAI, Anthropik qui nous parlent d'usines logicielles hyper automatisées et compagnie. Mais en fait, on sait qu'eux, ils ont des équipes en interne qui sont dédiées à la développeur experience, qui sont des gens qui sont dédiés à la création des skills, des gens qui sont dédiés à, tout un tas de choses, ce qui peut du coup amener une question de est-ce que cette usine logicielle c'est aujourd'hui un privilège qui est réservé aux très grosses boîtes parce qu'ils ont suffisamment, d'équipes pour aller être suffisamment précis sur certains aspects, ou est-ce que tu penses pour que les équipes à taille plus petite ou plus raisonnable, comme chez Alpic vous avez ce qu'il faut pour construire une usine logicielle, aussi complète qu'un Anthropik Aussi complète.

Nikolay — C'est sûr que non. Il nous manque quelques milliards, je pense, pour y arriver. Je pense qu'il y a deux choses. Je pense qu'OpenAI et Anthropic ont un énorme avantage en plus de leur dev, c'est qu'ils, peuvent utiliser autant de tokens qu'ils veulent. Ils n'ont pas de restrictions sur les coûts. Et nous, dans notre usine logicielle, on a vu qu'il y a plein d'endroits où on aurait bien aimé avoir un agent qui tourne à chaque paire. Mais si t'en as 15 qui sont lancés à chaque paire et qu'ensuite ça fait une loupe on a encore 10 qui sont lancés ensuite ça fait très très vite beaucoup, de tokens techniquement.

Bruno — Ils payent pas les tokens mais ils payent quand même le GPU.

Nikolay — L'inférence ils payent.

Bruno — L'hébergement il y a un chèque pour eux.

Nikolay — Derrière c'est vrai mais bon je pense qu'ils sont la marge sur les tokens est immense aujourd'hui ça doit être à 80% je pense, et donc ça c'est la première chose la deuxième c'est que je pense... En tout cas, nous, on s'est prouvé en 4-5 mois que c'est possible. Alors, notre software factory n'est pas aussi avancé, bien sûr, que les autres. Mais en soi, on a mis un dev sur le sujet, le lead sur le sujet. Et je vois pas mal de teams autour de moi qui mettent 2-3 personnes, si c'est des plus grosses boîtes. S'ils ont une centaine d'ingénieurs, tu peux facilement dédier 2-3 personnes sur ça. Et en fait, ça va assez vite, notamment parce que tu peux utiliser l'IA pour améliorer ta software factory. Et, c'est une des choses qui chez nous marche le mieux, c'est qu'on a tout simplement mis... Donc nous, nos agents peuvent être lancés depuis Linear, mais aussi depuis Slack. Et à chaque conversation on peut dire si, la session a bien marché ou pas et laisser un commentaire si elle n'a pas marché, et donc rien qu'avec ça on arrive à améliorer chaque semaine en fait rajouter une nouvelle feature un nouveau truc qui va faire que ça va marcher un peu mieux que la semaine d'avant.

Bruno — Est-ce que ça veut dire qu'il n'y a que cette personne là qui va améliorer, vos harnais ou votre usine logicielle de manière plus globale ou est-ce que c'est quand même un travail collectif et donc de plus en plus la tendance est de dire on ne corrige pas les problèmes ou les erreurs qu'on voit en prod ou les trucs, on corrige l'usine logicielle pour que l'erreur ne se reproduise plus derrière.

Nikolay — Alors, on fait les deux. On laisse l'usine logicielle corriger l'erreur en prod. Si elle arrive à le faire, tant mieux. Si elle n'arrive pas à le faire, on améliore l'usine logicielle, en effet, pour qu'elle puisse la réparer. Et donc, après, bien sûr, aussi, qu'elle ne reproduise pas l'erreur en prod avec ça. Mais oui, on passe pas mal de temps à améliorer l'usine logicielle. Et en effet, ce n'est pas qu'une seule personne qui le fait. L'usine logicielle utilise, des skills des instructions dans le repo et ça c'est le travail de toute la team dev d'améliorer ça chaque semaine on a d'ailleurs, un process qui est que chaque semaine on passe toute une après-midi à revoir, toutes les PR et regarder toutes les PR qui ont des commentaires, et ensuite réfléchir ensemble à des moyens de réduire le nombre de commentaires par PR, que ce soit des PR humaines d'ailleurs ou agentiques en partant du principe que bien sûr un commentaire ça veut dire que la PR n'est pas passée du premier coup, et donc ça on le fait manuellement aujourd'hui pour un peu apprendre et puis pour, lancer le truc mais c'est très facile aussi de mettre un process ensuite agentique qui fait la même chose et qui te propose des améliorations, chaque semaine sur qu'est-ce qu'il faut faire pour que ce commentaire-là, il n'aura pas dû être fait parce que ça, tu aurais pu avoir un linter qui vérifie peut-être cette syntaxe ou, une convention de code que tu aurais pu améliorer.

Bruno — Donc vous avez une personne qui est dédiée à ce sujet-là et un pourcentage de temps de tout le monde qui est aussi consacré à ça, mais qui n'est pas forcément fixé, j'imagine, c'est un peu libre. Mais tu saurais donner une fourchette à Vunet si on est plutôt sur du 5% ou plutôt sur du 25% ?

Nikolay — C'est difficile à dire, parce que ça se change de semaine à semaine, mais je dirais 10%.

Bruno — Et est-ce que quand quelqu'un va... Parce que, chaque développeur ou développeuse va lancer son ou ses agents qui vont faire des choses, il a du coup au final son harnais qui peut-être commence avec un cloud code ou un codex, je ne sais pas forcément ce que vous utilisez. Est-ce que chaque dev de l'équipe va pouvoir customiser son harnais et va du coup avoir son propre harnais très customisé, très spécifique à lui, et donc comme dans une équipe entre guillemets traditionnelle à l'ancienne chaque dev apporte un peu sa pierre à l'édifice en ayant une code base qui est un peu disparate ou est-ce que toute modification en fait est répliquée à tous les agents et donc au final, tous les agents codent pareil parce qu'ils ont tous les mêmes instructions ils ont tous le même harnais et donc tu as une code base qui devient de plus en plus hyper homogène, ce qui est plutôt il y a des bas moi chez la team c'est très bien.

Nikolay — J'adore une base de code homogène.

Bruno — Il y en a qui diront que c'est bien de varier un peu.

Nikolay — Pour moi en fait c'est un autre peut-être le plus gros avantage aussi de la, de l'usine logicielle c'est que ça homogénéise ta code base et surtout ça permet de, centraliser toutes les petites améliorations et toutes les connaissances que les devs. Ont appris avec l'IA, donc leur skill, leur façon de faire, etc. En fait, jusqu'ici, jusqu'à la Software Factory, tout le monde codait, comme tu disais, dans son coin et avait son propre setup qui marchait plus ou moins bien. Mais quasiment jamais, tu vas aller voir un autre dev et lui dire, mais c'est quoi ton setup, en fait ? Et le fait de devoir le centraliser avec la Software Factory, je pense que ça ne peut être que positif. Et du coup, pour te répondre, oui, nous, c'est obligatoire parce qu'en fait, avec la Software Factory, tu n'as pas de harnais à toi. Tu as juste un harnais dans le cloud qui est le même pour tout le monde. Après, on n'est pas encore à 100% d'utilisation du harnais parce que de toute façon, je pense qu'on n'est pas forcément encore à tout faire avec la Sofa Factory. Donc, quand c'est peut-être des trucs plus complexes, tu vas reprendre le sujet et tu vas le ramener sur ta machine. Mais le but, en tout cas, c'est qu'en effet, d'ici trois, six mois, tout soit développé par ces agents dans le cloud qui seront du coup tous les mêmes, sachant que quand même on a aussi la possibilité d'avoir des environnements différents pour chaque agent parce que si tu bas sur deux ripots différents, ce ne sera pas le même environnement que l'agent va avoir. Donc il y a quand même des différenciations mais surtout centralisées.

Bruno — Ok, canon. Est-ce que ce fonctionnement forcément on a évoqué tout à l'heure ces usines au Japon qui sont complètement dans le noir, cette image de la boîte noire n'était pas effectivement anodine, Comment est-ce que vous gérez cette approche de cette boîte un peu noire ? C'est-à-dire qu'au final, une fois que tu as créé ton agent, il génère du code, tout ce qui se passe dedans, tu ne le vois pas trop. Est-ce que vous avez des systèmes pour quand même regarder ce qui se passe à l'intérieur ? Est-ce que vous acceptez le concept de se dire « on ne sait pas » et puis on fait avec et on fait en sorte que l'entrée et la sortie soient le plus travaillé possible ? Comment est-ce que vous gérez cette approche boîte noire ?

Nikolay — Alors, il y a deux trucs dans la boîte noire, je pense. La première, c'est qu'est-ce que fait l'agent pour écrire le code ? Et là, clairement, on ne regarde quasiment pas. Tout ce qu'on regarde à la fin, c'est la paire. Mais c'est déjà le cas sur la machine d'un dev aujourd'hui. Je ne pense pas que qui que ce soit va regarder en détail tout ce que tu as écrit ou toutes les étapes de raisonnement de ton cloud code. Ce que tu regardes c'est le code produit à la fin, donc je pense que ça c'est pas très grave en soi tant que t'as des moyens de relire la paire et de vérifier ensuite de ton côté que le code marche, que t'as un ordonnement de preview pour tester etc donc je pense que ça ne change pas tant que ça par rapport à ça parce qu'encore une fois on a encore des humains, qui regardent le code et qui le connaissent.

Bruno — Et est-ce que ça a changé certaines routines ? Est-ce que ça a ajouté des routines à votre quotidien ou au final, c'était pareil avant et c'est juste que ça va plus vite maintenant ?

Nikolay — Alors oui, c'est vrai qu'on n'a pas parlé, mais c'est les routines de code, enfin des nouvelles routines plutôt. C'est aussi un des autres avantages de la Software Factory. C'est qu'il y a plein de choses, que dans une petite team, ou même dans une grosse, tu n'as pas forcément le temps de faire, parce que tu n'as pas l'argent, les ressources, etc. Typiquement, moi, j'aurais adoré avoir un ingénieur sécurité qui ne fait que, ou une red team qui ne fait que des pen tests de notre infra tous les jours, sans dormir. Avec l'IA, c'est possible, et c'est assez facile à faire en plus. C'est juste une task que tu schedules, avec du coup ces agents de code, si tu leur donnes assez de contexte ils peuvent faire des reviews de sécurité, ils peuvent faire si tu leur donnes un browser et encore une fois un environnement de staging et assez de contexte, ils peuvent faire de la QA, sur toute ton UI et te proposer des améliorations, ils peuvent essayer d'améliorer la performance de ton code, enfin il y a plein de routines comme ça que tu peux implémenter, auxquelles tu n'avais même pas pensé forcément avant. Et qui vont te ramener des vraies améliorations ok, Le seul problème de ça, parce que nous, on a implémenté trois ou quatre routines, de ce genre-là en sécurité, en perf, etc. Le seul problème, c'est que ça te rajoute des paires. Et du coup, il faut que quelqu'un les review aussi. Donc, il faut l'utiliser avec parcimonie et faire en sorte que tes routines produisent des paires que quand l'agent trouve vraiment des vraies améliorations et pas des petits trucs qui sont finalement insignifiants.

Bruno — Sur les étapes avant le dev tout ce qui est PRD spec et autres, c'est quoi aujourd'hui vous avez les agents qui vont vous aider à juste bien formater l'ensemble à s'assurer qu'il y ait tous les éléments dedans ou est-ce que ça va déjà pré-remplir beaucoup de choses est-ce que c'est une béquille à l'humain est-ce que c'est l'humain qui.

Nikolay — Dirige comment.

Bruno — Est-ce que le travail serait parti de ce côté là.

Nikolay — Ouais alors on a essayé pas mal de choses et, aujourd'hui ce qu'on a c'est plutôt, un fonctionnement en mode copilote où tu vas avoir des skills donc c'est même pas vraiment des agents en soi c'est des skills qui vont te permettre de bien écrire un PRD par exemple, qui connaissent la structure du PRD mais qui aussi ont des questions qui vont te poser, un peu en mode dialectique socratique je sais pas comment on dit pour, tout faire réfléchir mieux sur les futurs et aussi te permettre de ne pas oublier, certains angles quand tu l'écris, mais bon ce qu'on a vu comme je te disais c'est que si c'est l'agent ensuite qui produit, le texte final du PRD en tout cas, pas forcément de l'aspect que ça va encore mais vraiment la partie d'un. Product strategy, en gros. Donc, pourquoi tu fais cette feature ? Pour qui ? Quels sont vraiment les besoins ? On a essayé de l'écrire avec des agents, mais on voit que le niveau n'est pas encore là. Alors, peut-être qu'on est encore trop pointilleux sur ça, mais finalement, c'est parfois plus facile d'écrire moins et de ne pas avoir un PRD parfait. Mais où tu sais que chaque mot a été vraiment pensé et réfléchi.

Bruno — Donc là la PRD le document est encore écrit par des humains même si l'IA va les aider à s'assurer que tout est complet, tout est rempli il n'y a pas d'angle mort c'est ça.

Nikolay — Exactement il y a un truc quand même qui est assez cool c'est la partie product research donc aller voir, je ne sais pas, comment font, les leaders de l'industrie ou la compétition là t'as un agent qui peut te faire, des résumés assez cool assez vite avec même des screenshots, des vidéos de leur UI sur ça clairement ça aide, pareil pour le design, maintenant on, nous malheureusement on a pas de designer full time donc notre designer pour le coup c'est plus l'IA que les devs, avec l'IA et du coup on a un figma qui est ouvert avec un MCP connecté, à nos outils de nos agents et du coup on fonctionne par l'itération l'agent va faire des previews nous on va mettre des commentaires sur le figma et l'agent va repasser comme ça en itération à plein de fois.

Bruno — Et après du coup sur le passage côté on va dire dev avec l'aspect, tous les choix qui ont pu être faits avant est-ce que toute l'aspect est-ce que du coup elle est aussi entièrement généré ou partiellement par l'humain ou majoritairement par l'humain les choix d'archi sont écrits quelque part c'est purement de l'humain comment est-ce que vous gérez, toute cette traduction là.

Nikolay — Ouais bah c'est aussi assez mixte finalement pareil on a des skills qui peuvent aider mais qui ne sont pas toujours utilisés pour l'instant.

Bruno — En tout cas.

Nikolay — Et je pense que ce qui se passe souvent c'est que vu que tu as une personne qui est responsable de la spec il fait des aller-retours avec l'agent, pour l'écrire notamment pour générer du pseudo code des choses comme ça et ensuite il repasse dessus pour que ça soit facilement lisible et compréhensible.

Bruno — Est-ce que toute cette unité logicielle vous a apporté quelque chose au-delà du code, en termes de qualité, de rapidité, ce genre de choses. Est-ce qu'en termes d'organisation, chez Alpic, ça a été un gain pour vous ?

Nikolay — Alors, oui, clairement. Et en fait, bizarrement, depuis quelques semaines, notre software factory se transforme en quelque chose de plus grand qu'une usine spécifique pour le logiciel. En fait, depuis qu'on l'a branché sur Slack, on a toute la team qui commence à l'utiliser et on voit des usages qui n'ont rien à voir avec le fait de rajouter une nouvelle feature ou de réseau de un bug. Alors au début, c'était clairement pour ça, parce que ça ne savait faire que ça. Donc on a commencé à y mettre les bugs qu'on recevrait par mail, les feature requests de nos clients. Donc ça, ça ne marchait pas trop mal. Et puis ensuite, on a vu aussi que si tu lui donnes accès à ton Notion, à ton Drive, etc. En fait, ça peut faire beaucoup, ça peut tout faire. Et du coup c'est en train de se transformer en agent généraliste pour la boîte qui a le contexte de toute la boîte et moi c'est ça que je trouve le plus incroyable, dans ce projet c'est que maintenant on a des commerciaux qui utilisent, notre agent qui s'appelle Parallel chez nous pour générer des reports pour les clients par exemple. Et plein d'autres choses comme ça et donc en fait les gens s'approprient l'agent pour faire ce qu'ils veulent finalement, et du coup ça va au-delà de juste de la génération de code ou de l'amélioration du produit.

Bruno — Sur des aspects peut-être un peu plus économiques ma question elle serait un peu double c'est est-ce que tu arrives à, à estimer ce que tous ces éléments-là rajoutent en coût, par développeur ou par développeuse ou par gens côté produit on va dire, parce qu'on se ramener à ce côté unitaire peut être intéressant et est-ce que tu penses que ça t'a permis de recruter moins de personnes par rapport à ceux dont t'aurais eu à avoir besoin, par le passé ou est-ce qu'à l'inverse comme t'es capable de faire tellement de choses aujourd'hui t'as besoin de recruter encore plus de monde.

Nikolay — C'est une bonne question, ça. Sur le recrutement, je pense que ça nous permet de faire beaucoup plus de choses, c'est sûr. Est-ce qu'on aurait... En fait, quand tu es dans une startup, la contrainte, ce n'est pas forcément le coût. C'est aussi la vitesse à laquelle tu recrutes. Et nous, ça nous permet de faire beaucoup plus de choses qu'avant. C'est incroyable. Et donc, ça nous permet de mieux servir nos clients et les projets qu'on fait. Et c'est là qu'on voit vraiment l'amélioration. Et la première question, c'était quoi ?

Bruno — C'était sur le coût par personne de produit tech que vous avez. Ça représente quoi comme surcoût, que ce soit le coût en token ou les coûts en... Alors, tu nous as dit à peu près 10-20 balles par jour de sandbox. Mais au total, ça représente quoi ?

Nikolay — Alors, il faudrait qu'on regarde de plus près. On a un dashboard maintenant, qui analyse bien sûr le coût en token et en sandbox de chaque tâche, de chaque conversation. Je sais qu'on est à moins de on est moins de 1000 euros encore pour l'instant par mois, après on est encore en train de scaler ça va sûrement augmenter, je t'avoue que c'est pas trop un truc qu'on regarde parce qu'on utilise des crédits de start-up, de cloud pour l'instant on a assez pour vivre encore une bonne année avec ça je pense. Mais je pense que ça va finir autour des 200, 400 dollars par mois par développeur. Ce qui est en fait ce qu'on paye déjà aujourd'hui parce que chaque développeur chez nous a un abonnement de codex et cloud code à 200 balles par mois parce que c'est les plus gros, qui suffit largement par personne. À moins qu'on multiplie par 10 le nombre d'agents, je pense que ça va rester dans ces eaux-là pour l'instant. Sachant que c'est très facile de baisser les coûts de tokens juste en utilisant des modèles moins gourmands. Nous, on utilise notre sandbox. Donc, le harness derrière, c'est open code. Et donc, c'est d'autant plus facile d'optimiser les coûts ensuite avec ça. Donc, pour moi, ce n'est pas un gros sujet pour le moment.

Bruno — Je réalise avant de conclure qu'on n'a pas parlé de l'aspect CI-CD qui est quand même aussi un aspect important qui engrange du coup de plus en plus de trafic, comment est-ce que vous avez adressé ce sujet si tant est que vous l'ayez adressé ou peut-être que c'est pas encore un sujet pour vous aujourd'hui.

Nikolay — Alors on a pas fait grand chose pour l'instant, mais on sait qu'il faudra y passer c'est clair qu'il faut rendre ta CI plus rapide plus efficace. Chose qu'on a fait quand même, c'est qu'on a une routine qui va déployer maintenant, de manière argentique tous les matins, chose qui était réservée à un dev avant ça. Donc ça nous permet de déployer plus et plus rapidement. On veut mettre en place une sorte de, comme je te disais, une routine de QA qui va tester notre prod pour s'assurer que tout va bien après chaque déploiement aussi, en plus des tests déterministes. Et on a mis en place des triggers sur toutes nos alertes de prod aussi qui sont directement lues par un agent, plutôt que par un humain et qui nous permettent de mieux gérer ces choses là ça c'est deux trois trucs qu'on a déjà implémenté, l'idéal, Pour moi, que j'aurais bien aimé tester, c'est d'avoir un agent qui soit au nord de sa feature jusqu'au bout et qui, une fois qu'elle est émergée, qu'elle est prête à être déployée, va créer son dashboard de suivi pour cette feature spécifiquement, pour voir si les gens l'utilisent, s'il n'y a pas d'erreur, etc. Et qui va la suivre lui-même plutôt que ce soit des humains qui regardent. Et peut-être qu'après un mois on voit que la feature n'a servi à rien ou elle a plutôt apporté des avantages et donc l'agent peut décider peut-être avec un humain quand même à un moment mais il peut décider de l'enlever, de rollback ça c'est un peu l'idéal, pour moi de la CACD.

Bruno — Après le truc c'est que ton agent il vit que quelques minutes slash heures dans une sandbox donc lui demander de rester allumé pendant plusieurs mois pour surveiller une feature c'est peut-être...

Nikolay — C'est sûr, mais en fait, tu peux le run, tu peux le réveiller toutes les 24 heures.

Bruno — Oui, c'est vrai.

Nikolay — Il se réveille, il regarde les stats, et ils seront dans.

Bruno — Pour terminer, tu as évoqué tout à l'heure certaines limitations qu'on a aujourd'hui, sur ces modèles qui ont déjà pas mal de capacités, mais qui ne sont pas non plus capables de faire, le meilleur code de l'univers, même si on sait que c'est une donnée qui est variable. Et tu as évoqué ce terme que ces limites allaient disparaître petit à petit, moi depuis quelques mois que je travaille beaucoup sur ces notions de harnais, la sensation que j'ai c'est que la force du harnais c'est justement tous ces outils déterministes que tu mets autour, de ton modèle et que en fait ces limitations on va plus les atteindre, Alors, c'est pendant... Toutes ces limitations, on va plutôt les lever, non pas en ayant de meilleurs modèles, puisqu'ils sont déjà capables de faire beaucoup de choses, mais en ayant des meilleurs harnais déterministes autour. C'est aussi, je trouve, une des grands merveilles de ce que Claude Code a apporté sur tout ça. Et du coup, quand j'entends dire, en fait, l'IA, bientôt, elle sera capable de faire beaucoup plus. Alors déjà, je me souviens qu'il y a 15 ans, Elon Musk nous disait que la voiture autonome, elle serait là dans 6 mois. On l'attend encore, parce qu'on n'a pas encore sur toutes les routes du monde à travers le monde, ce qui montre bien qu'il y a des contraintes. Je continue à me dire que les modèles ne seront pas capables d'évoluer vers des gens... Enfin, de développer aussi bien que ce que des gens hyper experts sur Terre arrivent à faire, mais qu'avec les Arnais, on arrivera, en revanche, à lever ces limitations.

Nikolay — Oui, je ne partage pas 100%.

Bruno — Ok, vas-y.

Nikolay — C'est ta vie. Je pense que justement, les trainings de modèles ont tendance à absorber ce qui est fait dans le harnais, donc les contraintes des harnais. Et rajouter ces capacités-là directement dans les modèles grâce au reinforcement learning. C'est ce que j'ai l'impression de voir en tout cas dans les 12 derniers mois. Maintenant, un cloud code ou même d'ailleurs les autres modèles, la plupart des skills que tu lui avais fait il y a 6 mois ou 12 mois, elles ne servent plus à rien parce qu'en fait, il a appris naturellement et je pense que ça va continuer, quand tu vois combien d'argent les labs sont en train de dépenser pour avoir de la data de prod, de vraie boîte je ne sais pas si tu as entendu parler de ça mais tu as plusieurs brokers de data maintenant qui achètent juste la data de ta boîte si elle a plus de 2 ans si ta boîte, existe depuis plus de deux ans et qu'elle a plus de 20 personnes ils peuvent te payer 500 000 euros juste pour récupérer toute ta data, ton code alors anonymiser, tes échanges mail etc etc rien que ça, ça vaut de l'or pour les labs et la raison, c'est qu'ils ont besoin de data vraiment à grande échelle et de boîtes qui ont vécu dans le temps et donc de code lines de codebase qui ont évolué dans le temps, pour faire du reinforcement learning sur le fait de garder une code base saine et. Durable dans le temps. Parce que jusqu'ici, l'ERL, c'était, des tâches de une heure au début, ou même de quelques minutes au début, une heure, maintenant quelques jours, mais tu n'as aucun bench qui va regarder si le code que tu produis, ne rajoute pas de dette technique. Et je pense que les gens, enfin, les labs, quand même, jusqu'ici, ont réussi à résoudre tous les problèmes, qu'on évoquait il y a 6 mois, il y a 12 mois. Encore une fois, tu disais, il y a 15 ans, on parlait de voitures autonomes, certes, mais il y a un an, tout le monde disait, je ne vais jamais laisser l'IA coder à ma place.

Bruno — Et aujourd'hui, c'est révolu. Donc toi, tu vois plus le harnais, se déliter à travers le temps et que petit à petit on aura de moins en moins besoin de ces outils-là et que le modèle nativement sera capable de faire des choses.

Nikolay — Je pense, oui.

Bruno — Écoute, on pourra du coup peut-être refaire un épisode dans un an ou deux.

Nikolay — C'est ça, pour voir où on en est.

Bruno — Merci beaucoup en tout cas, Nicolas, pour toute cette discussion. J'aurais deux dernières questions pour toi qui sont les questions rituelles de ce podcast. La première, c'est est-ce qu'il y a un contenu que tu voudrais partager avec les auditeuristes ?

Nikolay — Alors, oui. je pense que si vous êtes intéressé par les software factory je vous conseillerais de regarder les vidéos de Dexter Horty, qui a fait pas mal de talks dessus, notamment à IA Engineer. Et bien sûr, aussi, toutes les vidéos et skills de Matt Pocock, qui est un grand gourou, alors maintenant de l'IA, avant plutôt de TypeScript, mais maintenant de l'IA, qui est toujours très, très, très pertinent.

Bruno — Il y a effectivement beaucoup de skills disponibles qui sont hyper intéressantes. Et dernière question, qui est la plus importante de ce podcast. Nicolas est ce que tu es plutôt espace ou tabulation.

Nikolay — Alors moi c'est 100% à tabulation depuis toujours parce que c'est beaucoup c'est en termes d'efficacité c'est c'est quand même beaucoup mieux d'appuyer une seule fois que deux fois sur surtout clavier.

Bruno — Merci beaucoup nicolas.

Nikolay — Merci à toi.

Bruno — Et merci à tous d'avoir suivi cet épisode voilà effectivement les software factory c'est un peu le sujet chaud du moment vous avez dû voir que depuis la rentrée on en a parlé quand même plusieurs fois sur différents aspects là on a effectivement le software factory qui est en prod qui est sur. Du code existant et pas de la réécriture ou genre de choses donc on est quand même sur des contextes qui sont de plus en plus génériques communs classiques et qu'on convient tous au quotidien donc c'est une vraie réalité j'espère que vous avez, renoté tous les conseils de nicolai sur sur comment faire ça il ya des choses à tester si vous avez des conseils à lui demandé, je pense que vous pouvez le retrouver sur les réseaux. Si vous avez des commentaires que vous souhaitez partager, faites-vous plaisir aussi sur les réseaux auprès de Nicolas et auprès de moi, ça fera aussi toujours plaisir. Moi, de mon côté, je vous remercie toujours de partager ce podcast autour de vous, bien évidemment. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien.