Comment sur-optimiser Claude Code pour shipper les yeux fermés - Gen AI Nantes #19

Bonjour à tous.

Comment choper les yeux ?

Mais comment on se sur optimiser Cloud Code pour choper les yeux ?

Le weekend dernier 36h, c'est la plus longue session en autonomie de Cloud Code.

Il a [grognement] tourné tout seul sur mon PC pendant 36h de suite sans planter quoi que ce soit.

Et pourtant choper les yeux fermés, ça ne veut pas dire en aveugle.

C'est tout le propos de cette présentation aujourd'hui. Je vais vous

présentation aujourd'hui. Je vais vous expliquer un petit peu la démarche que j'ai depuis plusieurs mois pour passer d'une approche où Cloud fait un petit peu ce qu'il veut, n'importe quoi, à quelque chose où on va le contraindre pour le forcer à aller dans la bonne

direction.

L'idée, c'est de commencer par un petit état des lieux. Qu'est-ce que Cloud ?

Qu'est-ce qu'il a sous la ? Qu'est-ce

qu'il a dans sa ?

Euh pourquoi aujourd'hui je doute quand j'utilise Cloud Code et je suis pas le seul.

Ensuite, la démarche. Je vais vous présenter un petit peu ce qui m'a amené à avoir ce regard orienté fiabilité.

Enfin, euh ce qu'on va mettre au niveau des remparts, comment on va le robustifier, lui interdire des accès.

Et à partir du moment où c'est mis en place, comment on passe à la vitesse supérieure en en déclenchant pas un mais plein.

Et enfin, une petite analyse rétrospective et bilan pour les suites.

Pour commencer, qu'est-ce qu'on a dans la ?

Bah moi, euh enchanté, je me présente, je m'appelle Cédric Charrier Filer. Je

suis président de la société Siliceum.

C'est une toute petite entreprise, on est un collectif de freelances spécialisés dans la performance et la fiabilité logicielle. Nous travaillons

fiabilité logicielle. Nous travaillons soit dans le domaine de l'industrie ou dans le domaine du jeu vidéo. Et moi,

les choses que je travaille au quotidien, c'est assez simple, les objectifs, c'est voilà, on doit distribuer une API en Europe complète.

J'ai 40 minutes max d'indispo par semaine. Ou alors, le travail sur lequel

semaine. Ou alors, le travail sur lequel je bosse en ce moment pour pour le domaine du jeu vidéo, c'est tu as 30 millisecondes pour afficher une page web.

Ça, ça va être mon prisme personnel qui va vous permettre de comprendre la présentation.

Et enfin, il y a deux obsessions qui m'habitent. La première, c'est la

m'habitent. La première, c'est la fiabilité et la perf, mesurée, corrigée, optimisée. Je veux que ça tourne, que ça

optimisée. Je veux que ça tourne, que ça tourne vite et que ça tourne bien.

Et la métaprog, euh, genre du monde de la recherche, moi j'adore le code qui génère du code, qui génère du code. Et

avec Claude, c'est génial parce qu'il génère plein de code et et souvent il a besoin d'être corrigé.

Je vais commencer rapidement sur une présentation succincte de Claude. Je

crois vous êtes un paquet d'utilisateurs de Claude déjà dans la salle, mais c'est histoire qu'on puisse connaître les leviers qu'on a à disposition pour pouvoir le contraindre. Pour rappel,

Claude Code, on ne parle pas euh du chatbot que vous avez sur votre navigateur, on parle vraiment de l'agent que vous allez ouvrir sur euh votre console de commande. Vous allez lui faire une bafouille et lui, il va

vérifier les fichiers, il va venir lancer des actions, les modifier, lancer des scripts et normalement, en théorie, c'est vous qui validez ce qui se passe.

En 30 secondes, un token, pour vous rappeler, j'ai une phrase, je la décompose et lui, il va déjà avoir transformé ça en signal. Le nombre de tokens, ça va définir la quantité d'espace que vous allez avoir dans sa mémoire.

Claude fonctionne avec ce qu'il appelle un contexte. Le contexte, c'est la

un contexte. Le contexte, c'est la taille de sa tête quand il va devoir travailler. Parce que dedans, il va y

travailler. Parce que dedans, il va y mettre des fichiers Claude qu'il va charger au début, les fichiers lus, toute la conversation que vous avez eue.

À chaque fois que vous renvoyez un message, il recharge tout. Et enfin, les prompts. En gros, un million de tokens,

prompts. En gros, un million de tokens, c'est chez moi environ 75000 lignes de code. Donc, on est loin d'absorber

code. Donc, on est loin d'absorber l'intégralité d'une base code legacy qui des fois explose en millions. Il va

falloir trouver des stratégies.

Claude fonctionne par principe de session. Ah oui, je vais commencer les

session. Ah oui, je vais commencer les gros mots, je suis désolé. Des fois, je donne des termes techniques. Si ça

coince, levez la main, n'hésitez pas.

Mais après, je vais commencer à expliquer chacune des étapes.

Claude fonctionne par session. La

session, ça commence au moment où vous allez commencer à parler avec lui.

Lui, il va changer son contexte. Claude,

son Claude.md, des règles, des skills qu'il a découverts. Puis,

il va lire mon intention. Il va lire mon compte submit. Là, il a activé les

compte submit. Là, il a activé les premiers skills. Et enfin, il va rentrer

premiers skills. Et enfin, il va rentrer dans une boucle où il va lire le fichier, éditer, lancer des scripts, lancer des tests. C'est là que se fait la moulinette. Et enfin, il vous dit

la moulinette. Et enfin, il vous dit quand il a fini. Ça, c'est une session.

Vous avez plusieurs manières d'utiliser Claude. En direct ou en interactif dans

Claude. En direct ou en interactif dans votre terminal. Ça, typiquement, vous

votre terminal. Ça, typiquement, vous l'utilisez au quotidien. Vous avez aussi une manière de l'utiliser en tiret P, en headless. En gros, vous pouvez

headless. En gros, vous pouvez l'intégrer dans une CI, dans un cron, dans un script, pas d'humain dans la boucle.

Jusqu'à normalement le 15 juin, c'était le même prix que l'interactif.

Ça devrait pas tarder à changer.

Maintenant, c'est payé au token API usage.

Et juste pour revenir sur les quatre modèles. En gros, Claude, c'est quatre

modèles. En gros, Claude, c'est quatre modèles. Haiku,

modèles. Haiku, le moins cher, celui qu'on lance sur les tâches qui sont massives. Typiquement, vous avez besoin

massives. Typiquement, vous avez besoin de lire une quantité astronomique de fichiers pour en faire une synthèse, une flopée d'Haiku, ça fait le café. Ça

permet de faire du balayage rapidement.

Sonnet, c'est celui que j'utilise usuellement pour pouvoir faire du code.

Le gaillard, lui, c'est un cheval de trait. L'idée, c'est que la plupart de

trait. L'idée, c'est que la plupart de mes cycles de développement passent dessus. Il écrit du code et on le teste.

dessus. Il écrit du code et on le teste.

Il est capable de relire une une une MR. C'est le niveau par défaut.

Est-ce qu'il est moins cher ? Ça se

négocie, ça se discute, parce qu'en fait, il a tendance à réfléchir beaucoup. Donc franchement, c'est à

beaucoup. Donc franchement, c'est à mesurer. Mais ça, on en discutera.

mesurer. Mais ça, on en discutera.

Et Opus, normalement, c'est le lourd.

C'est celui qu'on lance pour les problèmes complexes ou la planification.

Typiquement, vous allez dire à Opus "Ouh là là, j'ai un truc très compliqué, tu vas m'aider à le décortiquer." On

reviendra dessus. Et ben c'est lui qui va faire la grosse analyse et ensuite, on va envoyer le travail sur pour Sonnets.

Et un peu plus, il y avait femme de 5, impossible. Le tout dernier, le plus

impossible. Le tout dernier, le plus capable.

La semaine dernière, je buvais une bière et on dit "Oh là là, il est sorti." Le

soir en rentrant, je siphonnais tous mes tokens en trois comptes.

Je serai incapable de vous dire s'il est bon, il a juste fait une relecture de l'intégralité de mes skills.

Est-ce que c'est mieux qu'un 4.8 avec un bon ?

Aucune idée. Puis vu que je suis pas américain, j'en aurai aucune idée.

[grognement] Claude il a une mémoire. En fait, Claude euh c'est un serviteur que vous avez chez vous, sauf qu'en fait il il oublie tout ce qu'il fait une fois le terminal fermé, enfin ou presque.

Lui, il fonctionne avec une notion de contexte. C'est sa fenêtre de travail du

contexte. C'est sa fenêtre de travail du moment. Elle est jetable. Dès que vous

moment. Elle est jetable. Dès que vous faites un clear ou un compact, il y a plus rien. Donc il va falloir trouver des stratégies pour qu'il conserve de la mémoire.

En local, si on veut persister, il doit enregistrer des trucs. Il y a un fichier, un petit JSON L euh dedans, c'est l'outil qu'il utilise quand il vous voulez relancer une session avec résumé. L'idée, c'est qu'il va regarder

résumé. L'idée, c'est qu'il va regarder ce fichier, il va tout absorber et il va pouvoir sortir. Alors vous pouvez

pouvoir sortir. Alors vous pouvez l'utiliser pour ça.

Vous pouvez aussi l'utiliser pour analyser la manière dont vous utilisez Claude. C'est là où ça devient

Claude. C'est là où ça devient intéressant. Ou même vous pouvez

intéressant. Ou même vous pouvez l'utiliser quand vous voulez faire du l'affichage de d'interface qui va vous montrer les rouages de l'agent en temps réel. Ça c'est hyper c'est hyper

réel. Ça c'est hyper c'est hyper pratique. Le problème, c'est que le JSON

pratique. Le problème, c'est que le JSON L c'est local à une machine.

Et les notions de mémoire déportée.

Le plus connu, c'est le Claude MD. C'est

celui dans lequel vous allez il va s'injecter à chaque compte. Je vais

revenir dessus. Mais en gros, des fichiers dans lequel vous allez mettre de la data dure qui va revenir régulièrement.

Moi perso, j'utilise aussi des deux types de structures de données. Euh les

données qui sont stockées par API, dans lesquelles je peux faire des filtres, des appels, typiquement ticket Gitlab et tout ce qui va être autour de la DB.

Grosse base de données SQLite pour pouvoir stocker des métriques, de l'état. Bref, pouvoir stocker des choses

l'état. Bref, pouvoir stocker des choses un peu plus denses dans lesquelles je vais pouvoir faire de l'agrégation.

Rapidement sur le Claude MD, c'est ?

C'est un fichier dans lequel on va mettre du contenu.

Mais attention, moi je ne préconise pas de mettre un readme. Le readme, c'est un autre fichier qui vous explique comment ça marche. Ça, c'est un contrat. C'est

ça marche. Ça, c'est un contrat. C'est

le contrat que vous allez dire à Claude pour lui dire "Voilà comment tu dois bosser." Dedans, alors là, je l'ai mis

bosser." Dedans, alors là, je l'ai mis en français, vous pouvez lui parler dans la langue que vous voulez. Il est un peu meilleur en anglais pour français.

Mais dedans dans ce contrat, ça va être parti à chacune des sessions.

Mais comment on écrit un bon Claude ?

Comment ça ?

Moi, ce que j'aime bien, c'est lui mettre des règles permanentes, en gros ma Attention, tout ce que vous allez mettre dans le Claude MD va compter dans le contexte, ça va réduire vos tokens, donc plus vous en mettez, plus vous payez.

Donc il va falloir vraiment être malin.

Mais en gros, j'ai tendance moi à beaucoup mettre euh les notions de toujours ou de jamais. Toujours quand il se passe ça, fais ça. Jamais ne fais ça.

Et euh également ajouter des éléments qui sont intrinsèques, typiquement attention euh pour les questions de secret, utilise ça.

Bref, des règles permanentes qui vont être utilisées.

Le Claude MD, en fait, bah vous pouvez en mettre un peu partout, à la racine, dans votre local.

Ah ça, je reviendrai un peu après.

En plus du Claude MD, vous avez la notion de skill et de rule.

Le skill, je détaillerai, mais l'idée c'est que vous pouvez associer, par exemple des des post-fixes de fichiers comme .rs

pour dire "Quand tu as tel suffixe, va charger tel skill." En gros, c'est dire "Dans tel contexte, viens charger tel élément de mémoire." Ça peut être plein, ça peut être par un emplacement dossier

euh ou ça peut être lors d'un événement bien spécifique. L'idée, c'est de venir

bien spécifique. L'idée, c'est de venir déclencher des chargements de contexte lors d'événements précis.

Et les soirées à faire, on est où ?

Une trentaine de fichiers chargés à la demande.

Chargés à la demande, c'est vraiment ça ce qui est important pour éviter de tout polluer. Typiquement, à la racine, c'est

polluer. Typiquement, à la racine, c'est des skills. Les skills, on va revenir,

des skills. Les skills, on va revenir, c'est une approche protocolaire qui décrit des démarches étape par étape.

Et dedans, j'ai greffé aussi une notion de mémoire, en fait, toute la mémoire chronologique qu'on a eu au sein du dossier et des éléments qui peuvent être sensibles comme les éléments de sécurité par exemple.

Les Cloud MD, vous pouvez en mettre un peu partout.

Vous pouvez en avoir un global qui va s'appliquer à tous vos projets.

Vous pouvez en avoir un par projet.

Vous pouvez en avoir un par sous-dossier. Vous pouvez en avoir un

sous-dossier. Vous pouvez en avoir un par sous-sous-dossier. En fait, ça va

par sous-sous-dossier. En fait, ça va s'empiler.

Le gros intérêt avec ça, c'est que vous allez pouvoir personnaliser, spécifier selon chaque projet, mutualiser des éléments, aller du plus général au plus précis.

Typiquement, quand vous vous retrouvez dans le fichier de test du front-end, vous allez pouvoir mettre des éléments plus spécifiques relatifs au test du front-end. C'est là où c'est vraiment

front-end. C'est là où c'est vraiment intéressant. Vous allez venir composer

intéressant. Vous allez venir composer ces Cloud MD imbriqués.

Le skill, c'est ? Bon, en gros, c'est un dossier, un dossier dans lequel vous avez un skill handler intérieur qui va être chargé à l'allumage, qui va dérouler tout le protocole composable avec les autres.

Dedans, le nom, comment est-ce que ça se déclenche. Je préconise aussi de mettre

déclenche. Je préconise aussi de mettre une notion de version pour le monitoring, c'est vraiment idéal. Et en

fait, dedans, c'est un dossier, ça veut dire que vous voulez vous pouvez mettre d'autres choses, des assets, des templates, du contenu. Typiquement,

quand vous allez générer un ticket sur GitLab, vous allez pouvoir lui mettre dedans un script CLI qu'il va pouvoir invoquer pour faire le ticket, un modèle de template et un test qui va venir vérifier la structure du ticket que vous

allez envoyer.

Vous pouvez lui donner à manger, alors n'hésitez pas.

Les skills, du coup, vous pouvez les spécialiser par domaine. C'est là où c'est intéressant. C'est que vous allez

c'est intéressant. C'est que vous allez pouvoir les associer.

Le skill, c'est qu'on s'en moque, il porte sa porte pour frontière. C'est là

où c'est vraiment hyper intéressant.

C'est ce que je vous disais pour le front-end. Et moi, j'ai même des skills

front-end. Et moi, j'ai même des skills un peu particuliers qui me font l'audit de manière généraliste sur plusieurs de mes projets. Le gros gros intérêt, c'est

mes projets. Le gros gros intérêt, c'est qu'un skill, c'est composable.

En gros, j'ai un skill d'audit qui va appeler tous mes sous-sous-skills d'audit qui va ensuite appeler des skills d'écriture. C'est vraiment ça

skills d'écriture. C'est vraiment ça l'intérêt, c'est que c'est des briques qui vont venir se composer les unes les autres.

Au-dessus des skills, vous avez les commandes. Les commandes, c'est des

commandes. Les commandes, c'est des petits outils que vous pouvez utiliser directement depuis la console. Slash et

vous les utilisez.

Ce que j'utilise le plus, le plan. Le

plan, c'est la carte avant l'assaut. On

réfléchit avec lui pour définir pour réfléchir à une future.

Le goal, je l'aime beaucoup celui-ci. Le

goal, en fait, il va répéter un objectif tant qu'il n'a pas validé la condition que vous lui avez donnée.

Corrige-moi tous les tests tant que le taux de tests n'est pas tous les tests ne sont pas verts. C'est vraiment

l'objectif du goal. Ou voici une roadmap avec 50 éléments à faire, tu me dépiles les 10 tickets à réaliser.

Et après, les loops et monitors, ben, je vous avoue qu'en fait, il le fait à ma place, ce sale clown. Loop, il

va répéter toutes les N instants une même commande.

C'est pratique pour aller tester euh des choses ou répéter des choses Allez.

Typiquement, moi, j'ai des loops qui me permettent d'aller regarder périodiquement les logs de la prod pour voir s'il y a pas eu des cacahuètes.

Alors que le monitor, par exemple, j'ai une pipeline CI qui tourne, il va la monitorer jusqu'à tant qu'elle soit finie pour voir s'il y a eu des problèmes dans la pipeline.

Et après, vous pouvez faire les vôtres.

Vous pouvez les greffer au-dessus des skills et c'est parti.

Et en dessous de de Cloud, on a les hooks. Les hooks, c'est ? C'est des

hooks. Les hooks, c'est ? C'est des

leviers de personnalisation que vous allez pouvoir utiliser pour pouvoir lancer des actions, euh invoquer des scripts ou utiliser des skills. Vous

allez en avoir au tout début quand la session démarre, quand l'utilisateur commence à prompter. Et à chaque outil qu'il va utiliser, il y aura un hook avant après.

C'est bien pratique, par exemple, pour économiser des tokens quand il va vous vomir une quantité de data. Vous avez

votre linter, par exemple, qui vous dit tout ce qui va bien et tout ce qui va pas. Ben, peut-être que vous avez juste

pas. Ben, peut-être que vous avez juste envie de prendre juste tout ce qui va pas et vous lui envoyez juste ça. Et

vous vous économisez tous les tokens que vous ne lui avez pas envoyés. Le préféré

d'un de mes associés, c'est le prix compact parce que lui il a du mal à compacter régulièrement ou à nettoyer sa session.

Bah en gros, quand on arrive presque au moment où il va tout nettoyer, ça fait une on envoie un petit modèle qui fait une petite synthèse, hop, et pour la rouvrir à la prochaine session.

Ça c'est une un exemple d'une de mes d'une de mes commandes que je détaillerai un peu plus tard. En gros,

l'autopilote je lui dis "Tiens, je dis "Tiens, tu me tiens le backlog, tu prends N tickets, tu les répartis dans cinq work trees, tu fais les cinq déploiements et moi je relirai les cinq MR à la suite." L'idée c'est que l'autopilote il lance le le

développement sur plusieurs éléments avec des scripts différents et après moi j'ai plus qu'à relire complètement. Donc

c'est vraiment ça que je vais pouvoir vous expliquer un peu plus ensuite.

C'est vraiment l'intérêt de venir composer. J'ai aussi des commandes

composer. J'ai aussi des commandes d'audit, des commandes de diagnostic.

Vraiment, c'est ça le propre d'y être dans son environnement Cloud Code.

[grognement] Ça c'est une petite aperçue de ce qu'il y a euh du coup sur les projets dans la boîte.

Une dizaine de plugins installés. Le

Superpower, c'est une dinguerie hein.

Superpower d'Antropic, je vous le préconise. Dedans, c'est de la bombe.

préconise. Dedans, c'est de la bombe.

Des choses pour diagnostiquer, faire du brainstorming, du debugging systématique, j'adore. Le Playwright, ça

systématique, j'adore. Le Playwright, ça c'est incroyable. Vous allez lancer

c'est incroyable. Vous allez lancer votre test, il va vous ouvrir automatiquement votre navigateur, il fait les tests automatiques. Même en

dehors du test, vous avez envie de lui dire "Tiens, on va checker ça sur tel site." Bah il va ouvrir votre Playwright

site." Bah il va ouvrir votre Playwright et puis il va commencer à naviguer dedans.

Incroyable. Après, quelques éléments spécifiques, des skills, beaucoup de rules et le le plus gros, en fait, c'est pas du Cloud Code, c'est du script CLI d'éterminisme. En fait,

quand je vais répéter une action plusieurs fois, plein plein plein plein de fois, bah peut-être que c'est pas une IA dont j'ai besoin, mais c'est du déterminisme, mais une action que je vais venir répéter.

Du coup, on a les bases. Ça, c'était la petite présentation succincte de ce qu'on avait sous Cloud Code, on va pouvoir rentrer dans la partie un peu plus rigolote. En gros, une fois qu'on a

plus rigolote. En gros, une fois qu'on a ça, moi j'ai plusieurs questions.

J'utilise Copilot.

Il m'a généré beaucoup de code.

Mais est-ce que ça ?

Est-ce que c'est conforme à ce que j'ai ? Est-ce que c'est ce dont a vraiment

? Est-ce que c'est ce dont a vraiment besoin ?

Puis combien ça me ?

Et là, on arrive au moment du doute.

C'est le moment où on a le premier boss qui se montre devant nous, un grand méchant aux grandes dents et il nous montre qu'en fait l'outil qui paraissait magique n'est pas si magique que ça. En

fait, je suis pas tout seul à le penser.

Microsoft et Google avaient fait une sortie en 2025 qui disait que aujourd'hui, 30 % du code des grandes boîtes était écrit par l'IA. Ça allait

augmenter de plus en plus.

Veracode qui explique que 45 % du code qu'ils ont analysé hier portait une faille de sécu. Il y avait un super talk la dernière fois sur la sécu.

C'est des choses à reconsidérer, vraiment.

API Hero qui nous dit que ah, on a détecté 153 % des fautes de conception en plus dans le code généré.

Et le problème, c'est que tout ça, ça donne une illusion de correction. Vous

avez souvent relu du code généré par l'IA.

Ça ressemble à du code correct, ça a la tronche d'un code correct. Bref, même

vous, vous auriez peut-être pas fait mieux.

Et le problème, c'est que ce n'est qu'une illusion.

Là, cette fantaisie que j'ai trouvée rigolote à partager. Vous avez sûrement entendu parler d'énormément de gens qui ont eu des bases de prod qui sont tombées parce qu'ils avaient laissé les accès à Copilot.

Bon, ça arrive aussi avec des scripts de migration qui étaient mal configurés.

Là, ce qui a été rigolo, c'est qu'en fait, ils ont supprimé la prod, mais en plus, ils ont supprimé les backups.

Ça, c'était rigolo. Celui-ci, moi, il m'amuse beaucoup, c'est une issue sur Gemini sur En fait, ils se sont rendu compte qu'il y avait un bug sur le MKDIR sur Windows et quand il déplaçait des fichiers, ben il les supprimait.

Donc, ça a quelque chose hein depuis.

Mais l'agent au déplacement des fichiers sur Windows supprimer les fichiers qu'il est en train de déplacer. Il arrivait

pas à générer le dossier donc bah tant pis, c'est perdu. Ouh là là.

Et l'approche naïve qu'on Bah je vous avoue hein, le premier code code que j'ai utilisé, j'ai "Ouah, ça a l'air magique. Tiens, vas-y, fais-moi un

l'air magique. Tiens, vas-y, fais-moi un module de facturation." Alors là, il s'emballe, il part dans un tunnel, 20 minutes, il me fait un truc de fou, 47 fichiers, 1500 lignes de code.

L'interface elle a l'air presque correcte. C'est cool.

correcte. C'est cool.

Mais ça marche pas.

Et alors ça c'est trois bosses que j'ai rencontrés les derniers mois sur les trucs où ben ça m'a marqué et ça ça m'a dit qu'OK, il était temps qu'on arrête de coder comme un zinzin et qu'on mette un peu de confiance. Le fléau

multi-tenant. Une appli, je vais coder une petite appli dont je vous parlerai.

Trop content, ça marche bien, elle est multi-utilisateur, elle permet de faire des des checks du health monitoring sur des des sites distants.

Sauf que mon collègue se rend compte qu'il a accès à toutes mes données.

Alors on n'est pas du tout dans la même organisation.

Ah ça m'ennuie, ça fuit.

Le faux vert. Pourtant pourtant je l'ai fait tester avec un test qui marchait bien. Il m'a même dit que le test il

bien. Il m'a même dit que le test il était vert, il était OK. Et moi

naïvement, je me suis dit si c'est testé, c'est qu'il y a pas de bug.

Ah non, ça marche pas comme ça les tests.

Et le dernier bug d'il y a quelques semaines, je me suis rendu compte qu'en fait Claude il a aussi besoin d'informations sur le contexte dans lequel il s'exécute. Les tests

fonctionnaient, je m'en étais assuré, ça marchait hyper bien en dev. En prod, pas de problème, mais en fait je me mange des 503 en boucle. ? Parce qu'en fait l'agent, lui ce qu'il voyait c'était son

environnement avec le code. L'appli

tourne, mais pas l'environnement. Et le

drift entre la config et son fonctionnement font que pouf une cacahuète dans le potage.

Et enfin, je crois que ça c'est ceux qui me font le plus arracher les cheveux, faire de design graphique avec Claude, j'ai toujours un peu du mal.

Euh vous avez sûrement essayé euh de passer plusieurs centaines de sessions sur un moment de PC juste pour aligner une icône un peu plus à gauche un peu plus à droite et même dans la présentation vous verrez des icônes qui sont pas alignées quoi.

Voilà, bref quand vous mettez tout ça cumulé les bugs, le contexte, les choses compliquées et ben on arrive à un moment où on se met à douter.

Qui plus est, des fois tout passe et on se rend compte que ça n'a rien à voir avec le métier.

Ouais, c'est sa façon de bosser hein. Il

fait ce que vous lui avez demandé, il vient pas challenger. Mon collègue lui il le fait, Claude il le fait moins.

Tout est vert mais le besoin métier lui il est pas cohérent. Je m'explique.

Je peux me retrouver avec trois pages et sur les trois pages il a codé différemment le module de l'alt-check. J'ai vraiment trois

de l'alt-check. J'ai vraiment trois composants différents. Pour lui pas de

composants différents. Pour lui pas de souci mais c'est juste que lui il a implémenté chacune des pages individuellement. La cohérence ne fait

individuellement. La cohérence ne fait pas partie de son langage.

Du coup le doute est posé.

Comment on fait pour remettre un peu de méthode là-dedans, créer les premiers remparts et le ? Puis de le dérailler.

Je vais dire "OK mon coco, moi mon taf c'est la fiabilité, je vais te faire souffrir comme on fait souffrir les équipes. Tu vas voir, on va pas

équipes. Tu vas voir, on va pas rigoler."

rigoler." La démarche comment on passe d'un point unique à la chaîne.

Un peu de contexte, ça c'est l'appli que je vous expliquais que je codais comme un zinzin, un petit tas de monitoring de qualité continue. Comment je suis arrivé

qualité continue. Comment je suis arrivé à mettre un petit peu de contraintes et de règles dedans.

De novembre à février je codais comme un zinzin.

Je codais sur mon téléphone dans la baignoire, 3000 commits en peu de temps, freestyle durant la soirée de Noël, c'est très rigolo, ça marchait presque.

Des fuites dans tous les sens, ça marchait pas du tout, des bugs partout.

C'est un petit peu notre métier de fiabiliser. Est-ce que ce serait pas

fiabiliser. Est-ce que ce serait pas intéressant d'étudier comment on peut démêler tout ce truc infâme, fumant et ?

C'est quasiment un million de lignes de code parce qu'il en génère hein.

Pour faire quelque chose de plus simple.

Bon vous voyez c'est en février on est au mois de juin.

Du coup plutôt que de vous expliquer chacune des astuces à chaque fois, euh ce que j'ai fait c'est que je vais vous présenter la méthode et sur chacune des méthodes, des éléments qui sont propres.

Est-ce que c'est du ? Est-ce que c'est une ? Un ? Une ? Une étape CI/CD ou un

une ? Un ? Une ? Une étape CI/CD ou un juge à ? Une étape CI/CD, c'est ce qui

juge à ? Une étape CI/CD, c'est ce qui tourne dans un serveur distant quand j'ai enregistré que ça va tourner tout seul pour valider que ça marche. Et le

juge à l'LLM, c'est quand je fais analyser le travail d'un LLM par un autre LLM.

Tu es là ou tu es arrivé ou ?

L'idée c'est pour commencer, c'est de se dire OK, plutôt que de le faire faire tout d'un seul coup, on va méthodo une méthodo un peu plus propre en décomposant par petit bout. Donc passer

d'un prompt unique à une chaîne.

Pour cadrer, spécifier, découper, exécuter, vérifier et tracer le besoin.

L'idée c'est qu'à l'étape 5, on répond aux trois : est-ce que ça ? Est-ce que

c'est conforme à la ? Est-ce que c'est le vrai besoin de ?

L'objectif c'est que chaque maillon produise un artefact, un livrable.

Un livrable qui est structuré, qui a toujours la même forme, que je peux contrôler toujours, que je puisse vérifier. Donc par exemple, je vais

vérifier. Donc par exemple, je vais pouvoir générer une MR, je vais m'assurer que dans l'MR j'ai toutes les étapes qui sont dedans et que j'ai les critères d'acceptation et que ce soit versionnable pour revenir dans le temps

et me faciliter l'analyse rétrospective.

C'est quoi un ? Ben, ça va être une spécification, ça va être un plan documentaire, ça va être du code, ça va être Oui, je mets quelques gros mots aussi, un ADR ou un post-mortem, j'y reviendrai dessus.

Mais bref, un artefact, c'est un livrable qu'on peut relire, rejouer, éprouver.

Juste rapidement, je vais détailler l'approche entre la feature et le bug fix sur ma manière de fonctionner.

Le tout début est un peu différent.

Mais après, c'est le même tronc commun.

J'aime beaucoup le plugin brainstorming.

Donc en gros, quand j'ai un nouveau besoin sur une nouvelle feature, j'ouvre une session Cloud Code et avec brainstorming, il vient questionner et on répond. Skill que je vous conseille,

on répond. Skill que je vous conseille, l'idée c'est vraiment de venir défricher le besoin, de l'utiliser comme comme on dit ça, un partenaire d'exploration.

Euh, c'est le même travail quand vous vous mettez avec vos collègues autour d'une table sur le besoin.

Et l'intérêt c'est de faire effet de consigne.

L'objectif c'est qu'à la fin on puisse générer une intention explicite.

Pour la partie bug, aujourd'hui, je le contrains à commencer par isoler le cas. Est-ce que tu arrives à le ?

Oui, parce qu'en fait souvent, il part tout feu tout flamme en mode "Eh, je sais ce que c'est, c'est ça ton problème." et en fait il est juste

problème." et en fait il est juste complètement à côté.

Donc là, je dis "Non, non, non, tu commences." Je mets un petit skill,

commences." Je mets un petit skill, c'est un type de bugging, très très bien, je "Tu commences, tu le reproduis." Et une fois que c'est

reproduis." Et une fois que c'est reproduit, tu me fais un test qui me prouve que tu reproduis 100 % des cas.

Et ton objectif, c'est que tu vas itérer jusqu'à ce point que ce bug il passe au vert. Ça ne prouve pas qu'on a corrigé

vert. Ça ne prouve pas qu'on a corrigé tous les bugs, on vient juste défricher l'emplacement spécifique dans lequel on avait un cas particulier et on vient s'assurer qu'on l'a contrôlé. Et ensuite, une petite

l'a contrôlé. Et ensuite, une petite partie de LLM avec un skill qui va venir relire tout ça pour étudier le blast radius, l'impact que votre fix il peut avoir sur le reste de votre appli. Donc l'idée,

c'est de passer d'une étape où on lui dit "Corrige ça." à une étape où lui, il va reproduire, se rendre compte, de mettre en place le test de confirmation, le corriger, étudier l'élément. Passer de là

étudier l'élément. Passer de là je croise les doigts à "Ça marche un peu mieux."

mieux." Derrière, si vous voulez, on en a je vous présenterai les skills qu'on a en chez nous sur la partie d'écriture de tests.

Et sur la partie "Je corrige le test."

et la partie "J'implémente la feature que tu m'as demandée." il y a eu une phase de planification. Comment on passe de l'intention de correction ou d'implémentation à une tâche euh ?

Objectif du plan, comme le brainstorming, c'est qu'on réfléchit à comment on va créer une traduction entre l'intention et l'implémentation technique. Par où ? Quel besoin de

technique. Par où ? Quel besoin de traiter en ? Bref, on va venir ré-

traiter en ? Bref, on va venir ré- mettre sur la table un petit peu tout ce qu'il faut faire pour ensuite en définir un plan daté. En fait, on est en train de découper, hein. C'est un backlog

refinement dans lequel on vient spécifier chacune des sous-tâches.

Et l'intérêt, c'est que ces sous-tâches, on définit le chemin critique pour savoir ce qu'on peut faire en parallèle.

Et après, ouf, ça me fait des tickets.

Une fois qu'on a défini Donc là, c'est un petit exemple d'une spec, par exemple. Là, j'en ai une en vrai.

Je vous la montrerai, mais l'idée, c'est vraiment En fait, c'est notre travail au quotidien, hein. Vous quand on a des

quotidien, hein. Vous quand on a des gros tickets bien structurés, le titre, la catégorie, les pics auxquels je suis je suis rajouté, euh le contexte, les critères d'acceptation, euh les specs Gherkin qui sont centralisées

directement dans mon code. Ah, bah oui, j'ai fait internet.

Non, mais je vous le montrerai plus tard.

Mais du coup, vous avez une bonne ou grosse spécification bien bien méchante dans laquelle j'ai vraiment les critères d'acceptation, le contexte, critères de non productivité. Là, j'essaie de lui

non productivité. Là, j'essaie de lui faire injecter des screenshots pour qu'il puisse reprendre à posteriori.

Mais en fait, ça devient un état de la mémoire à un instant précis.

Et j'y injecte aussi les NFR, tout ce qui va être les contraintes non fonctionnelles.

Vraiment.

Par exemple, je dis "Écoute, mon grand, euh tu vas me faire une tâche parce que là, c'est vraiment très très lent. Il

faut que le premier affichage de l'écran, il soit prêt en 1,5 secondes et que le moment où je peux le premier élément, ça se fasse en 100 millisecondes. Ça, c'est vraiment ton

millisecondes. Ça, c'est vraiment ton objectif. Donc pour ça, tu vas

objectif. Donc pour ça, tu vas m'implémenter une petite tâche qui va passer sur le staging régulièrement, toutes les nuits. Et si ça plante X fois, tu le fais." Donc l'idée, c'est vraiment aussi de mettre en place des

contraintes non fonctionnelles pour venir cadrer l'environnement. Pourquoi

je fais ? Ben, un truc tout bête, j'en avais marre des écritures blanches sur fond blanc. Vous l'avez peut-être vu

fond blanc. Vous l'avez peut-être vu quand on fait un thème noir. Et ben,

j'ai dit "Écoute, mon grand, l'accessibilité, c'est obligatoire. Tu

vas te manger les specs d'accessibilité.

Si on l'a CFE, ben pareil, tu hors de question que tu me fasses fuiter euh des des mots de passe directement dans l'environnement, je veux pas d'API qui traîne, tu me check tout ça.

L'internationalisation Vous avez essayé de faire un peu d'internationalisation avec ? Ben, il laisse passer tout le

avec ? Ben, il laisse passer tout le temps des des petits bouts de texte en français, en anglais. Il a du mal.

Écoute, tu me saoules. Façon, s'il y a un bout de texte en dur qui est mis tu tu ça marche plus. Donc, ça fail si ça manque. Bref, moi je vous invite

manque. Bref, moi je vous invite vraiment à venir obliger des spécifications euh non fonctionnelles pour venir le contraindre au maximum.

On a donc découpé par livrable traçable.

Ouais, je suis désolé, les yeux fermés, mais il faut quand même les ouvrir pour les valider. Moi, j'aime quand même

les valider. Moi, j'aime quand même beaucoup valider les livrables un par un pour m'assurer que tout tourne.

Donc, l'idée en fait, c'est qu'on passe d'un statut de je code beaucoup à un "Ben, je valide un petit peu tout ce qui se passe et je suis plutôt d'accord avec les étapes qui me sont proposées." Donc

là, je verrouille, on ne code pas avant que j'aie validé l'étape.

Et ensuite, sur le développement, ben, c'est ce que je vous disais, spécialisation par domaine.

Je voulais juste expliquer un truc. À

l'époque, vous avez mis en place des agents. Des agents, c'était censé être

agents. Des agents, c'était censé être un gros compte qu'on allait lancer qui avait plein de compétences qui était adapté à un domaine précis. Moi, je

trouve que c'est moins bon que les skills qu'on peut actionner par rapport à des rules dans des contextes précis.

Après, c'est que mon avis. Il a

Il utilise encore mes agents.

Ça m'émeut parce que ça faisait longtemps que je les avais pas vus, mais souvent souvent, c'est les skills sur lesquels je m'appuie plus.

On a donc tout ce qu'il faut pour faire de l'exécution en parallèle.

On a des tâches qui sont spécifiées, qui sont livrées, qui sont documentées. On

commence à mettre des premiers garde-fous.

Et Claude propose des outils internes qui le facilitent bien. Depuis février,

par exemple, le work tree est natif. Le

work tree en gros, si vous utilisez Git hein, euh ça vous fait une copie de votre repo local dans un dossier précis. Moi, j'ai

des scripts de génération de work tree, il va me générer l'environnement, une branche par work tree. Comme ça,

l'objectif c'est que chaque agent qui travaille en parallèle, il se marche pas sur les pieds de l'autre agent. Parce

que sinon c'est une horreur, chacun modifie le même fichier et ça part n'importe comment. Bah chacun a son work

n'importe comment. Bah chacun a son work tree et fait son travail dans sa chambre.

Git derrière, c'est qu'après un pouf, on peut en relancer beaucoup de trous.

Ce que j'aime beaucoup, c'est le LSP. Le

LSP, ça vous parle ou ?

Quand vous ouvrez votre éditeur de code, c'est le truc quand vous avez écrit une bêtise. C'est celui quand vous cliquez

bêtise. C'est celui quand vous cliquez sur un outil où vous vous dites "Donne-moi toutes les références." Et il vous donne toutes les références. Ça, ça

nous fait économiser beaucoup de tokens parce qu'en fait, plutôt que d'aller lire un fichier complet, et ben il va avoir accès à la structure, l'organisation de votre code.

Comment il ? Ben Claude, il voit le LSP comme un IDE. Claude, il va dire "Mais je suis en train d'ouvrir mon mail point RSA. Attends, je l'indexe, je le type."

RSA. Attends, je l'indexe, je le type."

Claude, il dit "Est-ce que tu vois des ?" Ah oui, tiens, ligne 42, le type ne

?" Ah oui, tiens, ligne 42, le type ne correspond pas. Ligne 57, il y a déjà

correspond pas. Ligne 57, il y a déjà une valeur déjà enregistrée.

Et là, à ce moment-là, Claude, il va pouvoir lire ses diagnostics en temps réel et faire les correctifs.

Donc le gros intérêt, c'est qu'on attend pas d'avoir fini d'écrire sur un fichier pour détecter au plus tôt les problèmes que l'on a rencontrés.

Parce que bien avec le LSP, c'est qu'on peut en brancher des bricoles.

On peut caler des règles de linter maison.

C'est là où je lui dis "Ben tu vois, tu dois utiliser mon design system parce que si tu l'utilises pas et tu utilises des boutons natifs, pouf, une fessée."

Euh je vais pouvoir aller un peu plus loin en voyant l'AST greffe.

Je vais encore revenir avec des gros mots. Euh l'AST greffe. L'AST c'est la

mots. Euh l'AST greffe. L'AST c'est la manière de représenter votre code source sous forme d'arbre en gros.

Parce que votre compilateur ou votre runtime, il interprète votre code comme si c'était un arbre avec des petits chemins.

Et ben, l'AST grep, ça permet de contraindre votre code à des motifs précis.

C'est vraiment le contraindre à des motifs.

Je prends un exemple très concret.

Quand je fais une migration SQL avec l'ESP SQL, je lui dis "Attention, tu as le droit de créer des colonnes, mais tu as pas le droit d'en détruire."

Donc je vais le forcer sur les règles.

Ou quand il vient créer une nouvelle feature et qu'il vient d'ajouter une nouvelle page en vue, je lui dis "Attends, si tu me crées une nouvelle page en vue, tu es obligé d'intégrer la feature, le feature flag, donc la manière de

désactiver la feature en temps réel sur l'appli." Je peux vraiment créer des

l'appli." Je peux vraiment créer des motifs particuliers pour le contraindre, qui sont beaucoup plus économes que des regex et beaucoup plus faciles à écrire.

Puis Cloud il sait très bien gérer les les éléments en AST.

Et si vous avez pas ce que vous voulez niveau LSP, ben vous pouvez surcharger la marque de place locale pour injecter les propres vôtres. Moi j'en ai des maisons avec du du LSP juge, du HTML, du CSS qui vient me corriger les éléments

d'arrière. Vous pouvez vraiment aller en

d'arrière. Vous pouvez vraiment aller en chercher pour injecter les propres vôtres.

Et quand ça se tient près avec l'ESP, ben vous avez toujours l'option d'injecter dans un hook des scripts qui vont valider le travail qui est en cours.

Et les dames juges, c'est ? Ben, c'est

dire OK, on a implémenté tout ça. On a

fait une spec. On va rassembler les deux. Et les juges, ils vont aller

deux. Et les juges, ils vont aller analyser ça.

Moi j'en ai deux. Euh, j'en ai un qui vérifie la version du code modifié.

Lui, il vient s'assurer que le code blueprint qui a été demandé, l'évolution de la spec, a bien été validée à chaque étape. Donc

il va s'assurer que le test euh fonctionnel de BDD est bien implémenté, qu'il tourne, qu'il fonctionne et qu'il correspond à la spécification. Et j'en

ai un autre, lui, en modèle beaucoup plus en un peu plus gros, qui euh va aller relire le fond comme si c'était un relecteur humain. Donc l'idée

c'est que j'en ai deux.

L'idée c'est pas de me remplacer dans mon travail, c'est vraiment de me donner de l'aide dans la revue en me détectant des choses qui ne vont pas. C'est

vraiment de défricher au maximum ce qu'on aurait pu trouver.

L'idée c'est que la machine relise la machine. Alors j'ai même en local des

machine. Alors j'ai même en local des commandes pour faire de l'ultra review encore plus fort, encore plus costaud.

Vas-y.

La revue technique par les agents et enfin ben vous.

Et pour moi il y a des choses qui sont non négociables.

L'histoire de la donnée d'ultit tenant, ça marche bien sur un projet labo. En

clientèle, c'est hors de question. Tout

est relu obligatoirement mais c'est fléché.

Donc dans la pipeline, ces éléments de relecture sont relus annuellement. À mon sens, et c'est ce

annuellement. À mon sens, et c'est ce qui est en train de faire consensus partout hein.

Si c'est vous qui faites pousser le code par les agents, c'est vous qui en êtes responsable. Vous

accordez cette confiance à ce code-là, c'est votre truc. Donc si vous l'avez poussé, c'est de votre responsabilité.

Et ça c'est un truc que j'aime beaucoup parce que mes collègues humains, ils détestent les écrire. Mais alors le problème de code,

écrire. Mais alors le problème de code, c'est qu'il perd la mémoire à chaque fois qu'il ferme son sa session. Donc en

fait ça ça devient sa mémoire. C'est des

trucs que j'utilise beaucoup en tant qu'archi et que j'utilise encore plus avec les agents.

Typiquement, toutes les décisions d'architecture qu'on prend pour revenir dedans. Les ADR. Donc je prends ma

dedans. Les ADR. Donc je prends ma décision, tout process de réflexion pour qu'on a pris ça ou pas. Qu'est-ce qui a été fait à ce moment-là que le ?

On sait qu'on a mis la poussière sous le tapis, c'est de la dette mais on reviendra dessus. Et quand on reviendra

reviendra dessus. Et quand on reviendra sur ce sujet-là parce qu'en fait les ADR, il faut aussi les relire régulièrement, et ben on va pouvoir revenir re-challenger ce qui a été mis en place. Ça pareil, j'ai un skill

en place. Ça pareil, j'ai un skill recording decision où on discute ensemble pour au moment de la planification, ça va être invoqué par ces éléments-là pour les tracer de manière automatique.

Les rapports de livraison comme vous faites habituellement.

Les rapports de livraison pour dire voilà tout ce qu'on a fait, voilà tout ce qu'on a rassemblé ensemble et voilà ce qu'on a testé, ce qui manque encore dans le test à réaliser.

Pourquoi moi c'est plus pour les ? C'est

pour corréler les éléments de déploiement à une release, à une étape d'investigation pour accélérer le rythme de détection des bugs.

Analyse dans 6 ans les post-mortem. Moi

j'aime bien ce mot-là, c'est rigolo.

Le post-mortem c'est ? Crash prod, il s'est passé quelque chose, on remonte l'enquête. On vient de tracer tout

l'enquête. On vient de tracer tout l'historique de ce qui s'est passé avant que ça se passe.

Jusqu'au moment où ça éclate. Puis les

actions qu'on a mis en place pour le corriger rapidement et les fixes et les actions pour que ça tienne.

Donc la cause racine, les fixes et les actions de suivi qu'on a mis en place.

Et la dette assumée, vraiment tout ce qu'on a mis sous le tapis, on s'est OK, de toute façon on fera ça plus tard. On

le sait, on le sait bien. Ou

Bah ça c'est aussi générable. Vous

faites pour une phase d'audit sur une base legacy, les éléments qui vont vous dire "Ouh là, attention, il y a des trucs qui ne vont pas du tout." Ça

permet de faire remonter les éléments de dette. C'est un bout de backlog à faire

dette. C'est un bout de backlog à faire remonter.

Et le post-mortem, moi je le déclenche pas quand la prod euh longtemps j'ai trois fixes par clone qui ne marche pas typiquement. Corrige-moi

la couleur du texte blanc sur ce fond blanc. Une fois, deux fois, trois fois.

blanc. Une fois, deux fois, trois fois.

Au bout de trois fois, on fait un post-mortem en mode OK, ça marche pas.

Euh analyse-moi tout ce que tu as fait et comprends ce qui bloque dans la méthode pour me proposer une action. Bon

des fois ça suffit pas.

Et si j'ai un post-mortem, deux post-mortem, trois post-mortem, alors on fait un post-mortem en mode OK, bah peut-être que si la méthode elle marche pas, donc il faut qu'on revienne sur la manière d'écrire le post-mortem pour

pouvoir réécrire cette méthode. Mais

l'idée vraiment, c'est que chaque problème rencontré devient une opportunité d'amélioration de la méthode de travail.

Maintenant qu'on a posé la démarche, on va aller encore plus loin dans la manière de borner.

C'est le moment où on met des grosses murailles autour du château, on hisse la R, c'est parti mon kiki, les zombies ne passeront pas.

Ouais, ça c'est juste parce que je trouve que c'est ultra nécessaire mais en même temps c'est obvious mais important. Pour moi Claude, il a fait ce

important. Pour moi Claude, il a fait ce qu'il veut sur la dev ou le local, hein, c'est freestyle, il a même intérêt de jouer avec tout. Par contre, sur la pré-prod, ben il peut écrire itérer mais

s'il l'autorise, il peut exécuter des commandes s'il l'autorise, il peut déployer s'il l'autorise. Tu touches pas aux datas parce que je suis jamais vraiment sur vraiment anonymisé ou pseudonymisé. On connait les datas de

pseudonymisé. On connait les datas de prod qui trainent en pré-prod, hein, donc non.

Et par contre, tu as tout à fait le droit d'aller lire les données de log.

Et alors en prod, tu touches à rien.

Donc ça veut dire que même les scripts de migration tu touches, voilà. Et vous pouvez le contraindre,

voilà. Et vous pouvez le contraindre, vous avez des petits fichiers de config sur lequel vous pouvez lui spécifier des environnements, des permissions et même des permissions faire outil.

Alors comment je fais pour lui donner accès à la prod sans lui donner mes clés de la ? C'est là où j'aime bien utiliser

de la ? C'est là où j'aime bien utiliser le MCP. Typiquement, moi j'ai une prod

le MCP. Typiquement, moi j'ai une prod complète dont les datas vont être ingérées par un un ver fan à l'outil par exemple qui a une API et qui exige des credentials pour être connecté. Alors si

je le mets dans le le cloud, c'est bien gentil mais ça fout tes hops, tout le monde y accède.

C'est pas dans le contexte du serveur MCP, je le mets au milieu. Le MCP

serveur qui va se rendre disponible aux agents pour leur dire voilà, j'augmente tes capacités, tu vas pouvoir interagir avec un élément extérieur. A l'échelle d'entreprise, ça

extérieur. A l'échelle d'entreprise, ça permet d'être le coffre qui va faire le lien entre l'agent et le MCP. Alors là,

j'ai les zéro credentials mais quand vous travaillez à plusieurs, ben vous pouvez avoir une notion de clé juste entre vous et le MCP et ensuite c'est le MCP qui gérera l'authentification de ton serveur de log.

L'idée en plus, c'est que vous pouvez chiffrer la data.

Donc dans le MCP, vous allez pouvoir lui donner des manières précises d'interpréter les logs sans qu'il en mange trop.

Vous voulez analyser s'il y a eu des bugs de prod critiques durant la la ben vous le retournez, juste ce résultat là, ça suffit.

Moi j'ai des scripts hein, qui qui font ça et ça marche super pratique et j'ai des scripts qui l'expliquent comment bien utiliser le MCV. Ouais, il faut le biberonner hein.

Et ensuite, à partir du moment où on peut augmenter la parallélisation, ben je me place des garde-fous. Typiquement,

pas plus de 5 MR parce que moi après euh si j'ai trop de MR, les conflits, ça part en cacahuète.

STQB, ni plus ni moins. Pas plus de N tâches simultanées à chaque étape. Pas

plus de N work stream. ? Ah parce que j'ai pas un espace de stockage infini et quand on fait de la compilation Rust sur son ordinateur, il y a un moment il y a plus de place.

Et limiter son geste. Euh je vous ai expliqué les petites actions que peut avoir votre Cloud, vous pouvez les configurer selon les contextes d'utilisation et des scripts qu'on prépare, des scripts, tout ce que vous voulez pour scanner que

aucun secret ne sorte.

Moi la petite contrainte, c'est que vu que je suis en phase de R&D, si ça plante, ben il bloque pas le travail, il laisse passer mais il le notifie.

Mais ça c'est une politique à appliquer au contexte d'exécution.

Et comme je vous disais, l'objectif c'est que un incident devienne une règle, un oubli qui fait chuter, une règle qui le détecte et Cloud s'enrichit au fur et à mesure. L'idée c'est que plus on l'utilise, plus il apprend notre manière de

travailler et plus il évolue dans le bon sens.

Les gens du monde du testing, ouais, je trouve affreuse la manière dont ils écrivent des tests, ça me fait euh ça me fait ça me fait trembler des doigts de pied. Du coup, la manière dont je dis "Écoute, euh moi j'aime bien STQB, il a des bonnes

pratiques. Donc dans son skill de test,

pratiques. Donc dans son skill de test, je dis "Écoute, inspire-toi des meilleures pratiques et du protocole de testing chez STQB."

Pareil sur la manière de venir interagir avec une page, on différencie la manière d'interfacer la page avec euh le test réalisé. ? Parce que sinon ça part en

réalisé. ? Parce que sinon ça part en cacahuète et ça devient intenable. Euh

la stack test, la pile de test, pour moi c'est un logiciel à part entière avec les mêmes procédés d'ingénierie logicielle que votre appli à barre.

Là, je l'ai mis à 77 parce qu'elle est rigolote.

No focus test, ça veut dire ?

Bah en fait, pour vous dire que il y a plus de problème dans le test, mais des fois il le désactive ou il le supprime.

Ah quand il y a pas de problème, s'il y a pas de s'il y a pas de thermomètre, il y a pas de problème.

Donc là, je lui ai interdit de skipper des tests ou d'en supprimer ou même de réduire la coverage, en gros me supprimer des tests pour que ça passe mieux.

J'aime bien l'utiliser aussi pour me générer des générateurs de data que j'utilise pour les tests.

Moi, j'ai pas un clavier japonais et pour tester les noms japonais sur une application, c'est hyper pratique.

Donc en vrai, il vient me consolider Ah, et ben j'ai plus de batterie.

C'est bon.

Il vient me consolider la surface de testing en ayant des tests les plus les plus spécifiques. Et couplé à l'ISTQB,

plus spécifiques. Et couplé à l'ISTQB, il va me permettre de me proposer des jeux de données qui correspondent aux cas que j'ai pas forcément envisagé. Est-ce que tu as

forcément envisagé. Est-ce que tu as bien testé la valeur la plus basse, la plus haute, un peu plus que la plus haute, un peu moins que la plus basse, de manière intelligente.

Et même si c'est très bien, pour moi c'est c'est c'est le feu, c'est trop bien. Ça ouvre le navigateur, ça

bien. Ça ouvre le navigateur, ça interagit avec, ça le pilote, ça s'utilise pour le plein de choses, le scraping, ce que vous voulez. Trop bien.

Le problème, c'est qu'à partir du moment où vous l'avez branché, chez moi il l'utilisait tout le temps même pour tester une addition. Ah trop cool, je vais le tester sur la plateforme si ça marche bien l'addition dans le fond.

Bah non, un test unitaire, ça suffit.

Parce que le test ne prouve rien. Oui,

parce qu'en fait il me génère plein de tests, mais un test ne prouve pas qu'il y a pas de bug.

Faut juste qu'il existe ou qu'il a structuré une petite partie.

Toutes les nuits, euh je viens faire des flaky tests. En gros, je vais relancer

flaky tests. En gros, je vais relancer les tests plein de fois et je vais détecter ceux qui plantent à un moment.

? Parce que des fois, il attend un certain nombre de secondes que la page s'ouvre et en fait ben ça marche pas parce que tu t'appuies sur des choses qui sont pas déterministes.

Bref, l'idée c'est qu'on détecte ce qui va plus pour les reprendre.

Et on fait aussi des tests de mutation toutes les nuits. L'idée c'est qu'en fait, il vient tester les codes, il dit c'est OK. En fait, il est toujours vert,

c'est OK. En fait, il est toujours vert, même quand je modifie le code. Donc si

le test est toujours vert, même si ce qui est censé tester ne marche plus, ben, ça sert à rien parce qu'un test qui ne tient pas est rassurant, il donne une impression de confiance là où il n'y en a pas.

Même un débat qu'on a eu ce matin avec mon associé, le problème c'est que avec cette approche-là, on a tendance à générer beaucoup de tests qu'il va falloir maintenir. Donc je fais vraiment

falloir maintenir. Donc je fais vraiment faites attention à ça. Et ça ça a plus une donner l'impression de de rassurer [raclement de gorge] alors qu'en fait, ça devrait être utilisé dans une méthode de

développement. Donc ça ne n'est pas

développement. Donc ça ne n'est pas suffisant et à mon sens, avoir un regard d'Aurigeot sur les tests générés est hyper important.

Et l'idée c'est que avant que ça parte en prod, toujours trois intentions.

J'insiste, je suis désolé, mais c'est pénible. Aucun secret ne sort. On

pénible. Aucun secret ne sort. On

s'assure que le code est propre, puis qu'on regarde le rendu.

Et en gros, ça ressemble à quoi entre chez moi jusqu'à la ? Ben, j'ai les étapes avec plein de codes et scripts qui sont lancés qui testent le format, le lint, les tests, la CI complexe. Mais

ça, j'invente rien, c'est la même chose que n'importe quel procédé industriel.

L'idée c'est juste de donner un Claude.

OK, en fait, si tu es développeur dans ma team, tu vas respecter la même manière de bosser que mes autres collègues dans ma team. C'est juste que je vais juste te donner les règles pour fonctionner. Je te donne mes process, en

fonctionner. Je te donne mes process, en fait.

Et je donne même accès à quelques métriques de prod, c'est là où ça m'intéresse. Donc voyez, ça ça ça juste

m'intéresse. Donc voyez, ça ça ça juste un petit exemple histoire d'en vomir, mais on en teste des tas de trucs qu'on en testerait un peu partout, mais le problème de Claude par rapport à un collègue humain, c'est que le collègue humain, il a

tendance à faire un peu plus que ce qu'on lui demande. Déjà, il va le tester sur son ordi, puis il va se rendre compte au weekend field que c'est un peu lent quand même, c'est un peu cassé.

Et puis, il va en parler à la machine à café, on va en parler autour d'une réu.

et en fait c'est avoir une mémoire qui va s'empiler les logs. Non.

Donc il faut vraiment venir construire avec lui une méthode qui évolue au fur et à mesure pour lui donner de plus en plus de contraintes. En tout cas, il est fait de contraintes.

Et tout ça ben je le robustifie avec l'observation en prod parce que on va en laisser passer des bugs. De toute façon, il y a toujours des bugs qui passent.

Mais l'idée c'est pas de savoir de les compter, l'idée c'est de connaître le temps qu'on met à les détecter et à les réparer. Donc tout ça pour moi doit être

réparer. Donc tout ça pour moi doit être par une vraie notion de monitoring intense. Donc

intense. Donc structurer correctement ses erreurs, avoir des bonnes métriques sur ce qui se passe sur la bécane, même les métriques business. Moi j'aime bien mettre les

business. Moi j'aime bien mettre les métriques business pour voir quand est-ce que ça part en cacahuète. Ah,

aujourd'hui on a eu zéro inscriptions.

Est-ce que c'est pertinent d'avoir zéro ? J'ai eu zéro création de chat sur mon

? J'ai eu zéro création de chat sur mon appli. ?

appli. ?

C'est étonnant.

Je check aussi à tous les events de déploiement, de redémarrage de runtime pour corréler.

Je veux savoir pourquoi j'ai une régression à un endroit précis. Je vais

pouvoir dire "Ah bah oui, on a eu un déploiement hier soir, c'est sans doute par rapport à ça."

Et Posthog, enfin du du monitoring utilisateur, l'idée c'est d'aller ensuite analyser le comportement que les utilisateurs ont sur l'appli pour pouvoir détecter ce qui bloque. Si vous

voyez par exemple que votre utilisateur il clique comme un frénétique sur le bouton sign in, bah c'est peut-être parce qu'il y arrive pas.

Et Cloud il est capable de le détecter ça ? Je donne tout ça. Juste attention

ça ? Je donne tout ça. Juste attention

en plus des mots de passe, il y a aussi la notion de RGPD et il y a des choses qui ne doivent pas passer côté côté logs. Euh pareil,

rajouter des garde-fous dans la manière dont je fonctionne avec lui, en le forçant à ne par exemple ne pas tracer les emails ou les données personnelles dans les messages de logs ou les mots de passe.

Mais l'idée c'est que l'agent doit aussi lire lui aussi les monitorings.

Parce qu'en fait Ah oui, ça j'en ai pas parlé.

Je monitore l'appli, je monitore la prod et je monitore aussi l'agent.

Donc à chaque fois qu'il fait une action, à chaque fois qu'il appelle un outil, à chaque hook, je monitore l'intégralité de ce qu'il fait et quand il se plante. L'idée comme ça, c'est que dans la boucle, ben il va pouvoir s'améliorer tout seul.

Et derrière, on va prendre tout ça et on va avoir un agent derrière qui va s'appuyer sur toutes les données de manière régulière, proposer des routines pour proposer la réduction du temps de

détection et de correction des bugs.

Mon histoire du bug des stacks des 503, je me suis amusé à rejouer le bug pour voir combien de temps on mettait. À

l'époque, on a mis 50 minutes pour détecter le souci. Là, le la grosse idée, c'est qu'en le branchant tout le système de prod, il a détecté de lui-même le souci, il m'a proposé un fix dans la foulée que j'ai pu valider en

moins de 15 minutes.

Bon, alors ça, c'est des petits trucs auxquels je m'amuse parce que des fois ça suffit pas. Alors, j'ai pas suffisamment de copains qui testent mes applis. J'ai des applis qui se baladent

applis. J'ai des applis qui se baladent tout seul sur les applis. Euh et l'idée, c'est qu'elles vont faire ça de manière déterministe, mais des fois elles savent pas quel chemin prendre. Alors à ce moment-là, elles invoquent un Claude qui lui dit "Tiens, euh voilà tout ce que

j'ai parcouru, propose-moi d'aller plus loin." Et lui, il vous dit "Ah, tu veux

loin." Et lui, il vous dit "Ah, tu veux aller faire une ? Ben peut-être que va sur la page de produit et ensuite va jusqu'au panier."

jusqu'au panier." L'idée c'est que ça va me générer de nouveaux signaux. J'en récupère toutes

nouveaux signaux. J'en récupère toutes les datas que j'ai sur mon navigateur, les requêtes réseau, le temps de latence, que je vais pouvoir utiliser pour debugger de manière systématique.

Ça marche super bien avec Cloud Watch par exemple.

Mais l'idée c'est que l'IA ne court-circuite rien. Elle est obligée de

court-circuite rien. Elle est obligée de passer de l'intention à son écriture, on la verrouille et on observe.

L'idée c'est des remparts, c'est que vous ne passerez pas.

Rien ne passe sans franchir chaque maillon.

Bon ben du coup, euh si tout marche hyper bien, on peut lancer, lâcher les chiens et passer à la vitesse supérieure parce que pour Pôle Emploi, on peut maintenant lancer 50000 agents.

Ouais, c'est là où je suis en train de me perdre en ce moment, j'ai l'impression de jouer avec des milliards de Tamagotchis.

La manière naïve, je discute au clavier avec lui sur un terminal. Est-ce que tu peux me corriger dans la pagination de l'écran ?

La deuxième, un peu plus amusant, je le lance directement en commande P, corrige le ticket et puis tu me génères un format JSON.

Bah du coup, on peut générer des scripts qui invoquent tout seul Cloud.

Euh par exemple, j'ai un hook comme j'ai reçu un ticket Gitlab, analyse-le et dépile-le. Ou toutes les 5 minutes, tu

dépile-le. Ou toutes les 5 minutes, tu vas voir s'il y a un nouveau ticket et puis dépile-le.

Maintenant, quand j'appuie sur entrée, c'est parti, ça c'est le début de la folie. Euh l'idée, c'est de dire j'ai

folie. Euh l'idée, c'est de dire j'ai deux méthodes. Soit je mets le workflow

deux méthodes. Soit je mets le workflow dans Cloud, donc c'est-à-dire que je vais tout mettre le protocole dans les styles, ou alors je fais l'inverse.

Et je mets Cloud dans le workflow.

Ben l'idée, c'est qu'en fait je facilite son onboarding en disant ma chaîne va invoquer plusieurs Cloud à des instants précis.

Je m'assure, je lui verrouille la manière de travailler. Oui, parce qu'en fait, il y a une vilaine tendance quand vous parlez beaucoup avec lui, il aime la data et puis quand il en a trop, il compacte. On reprend, il compacte. Et

compacte. On reprend, il compacte. Et

quand vous faites l'accordéon, au bout d'un moment, il perd un peu la mémoire et ce que vous lui avez demandé de faire de manière rigoureuse, passe complètement à côté. C'est comme si vous lui avez donné beaucoup trop de bière, c'est affreux.

Et pour moi, l'objectif, c'est l'inversion, passer de l'un à l'autre.

C'est comme ça qu'on se retrouve avec un démon qui à chaque fois que j'allume ma bécane, lance automatiquement l'usine et c'est en train de se lancer sur un serveur, mais l'idée, c'est que bah je fixe le périmètre.

Toutes les 5 minutes, il vient checker s'il y a des soucis, dépile un ticket.

Et là, il déroule tout ce qu'on vient d'aborder. Il s'assure que déjà tout

d'aborder. Il s'assure que déjà tout tombe bien en local.

On planifie, il exécute et j'ai une phase de review.

Les garde-fous, pas plus de deux agents en simultané. Alors, pourquoi pas plus

en simultané. Alors, pourquoi pas plus de deux ? Ben parce que ben tout ça, ça

de deux ? Ben parce que ben tout ça, ça demande du compute. Donc vos bécanes, elles sont pas infinies. Donc après, il faut commencer à distribuer les usines sur plusieurs ordinateurs. Enfin, ça

devient On commence à faire de l'orchestration de compilation.

Bref, une grosse contrainte, c'est qu'au bout de trois échecs sur une même tâche qu'on vient répéter, on fait une pause et on dit "OK, là, j'ai besoin d'un coup de main, aide-moi, je suis bloqué. Cédric, aide-moi." C'est

là où il fait "Moi, je peux mettre en pause quand je veux, mais le merge reste mon outil." Et ça, c'est deux scripts,

mon outil." Et ça, c'est deux scripts, hein, c'est un script démon qui va lancer euh qui tient la boucle et le run qui lance le process.

Ce que j'aime bien derrière, c'est que l'usine peut entretenir l'usine parce que du coup, vous avez l'appli, mais vous avez l'appli qui génère l'appli.

L'idée, c'est que vous allez capter tous les signaux qu'on a évoqués. Ah, ça a planté. Ah, j'ai tracé les bugs. Ah,

planté. Ah, j'ai tracé les bugs. Ah,

c'est revenu en arrière.

Tous les éléments qu'on a mis derrière, on récupère tout.

On les accumule, on a de la data. Ça, c'est des vraies données, hein, c'est le nombre d'applis euh GitHub que j'ai fait la semaine dernière.

C'est j'accumule tout ça, le nombre de flux de dossier, le lancement de tests, toutes les choses qui se répètent.

Tous les soirs, j'ai une phase d'analyse, il va comprendre tout ça en disant "Voilà tout le bazar que j'ai fait, ce que j'ai mal compris et je te propose qu'on améliore." Il propose des pistes

qu'on améliore." Il propose des pistes d'amélioration pour optimiser le workflow et son usage parce qu'il fait partie du workflow.

Et une fois qu'il m'a proposé toutes ces traces, c'est proposé, il a proposé des pistes d'amélioration en mode "Ah, attention, tu as fait la même commande 178 fois, peut-être que ce serait intéressant de

faire une commande juste pour ça, un petit script.

Ah, tu feras attention, tu consommes énormément de tokens sur telle commande, peut-être que ça vaudrait le coup de réduire la data que tu injectes.

Ou il y a des liens cassés ou d'autres règles qui peuvent arriver.

Le nombre de mesures en continu, ben, ça va être le temps de détection d'un bug, par exemple, en prod. L'objectif, c'est

d'itérer pour que ça diminue de plus en plus, le nombre de régressions que j'ai pu avoir sur mes livraisons, le nombre de fixes auto proposés. J'ai

détecté un souci, je propose un fixe jusqu'à la jusqu'à la MR et l'autonomie complète. L'idée,

c'est vraiment de détecter quand est-ce que ça arrête le flow et quand est-ce que ça l'oriente.

Juste un petit un petit élément de contexte.

Euh Claude, il a une vilaine tendance, c'est que il ne vous explique pas vraiment comment il fonctionne en interne. Des fois, il fait n'importe

interne. Des fois, il fait n'importe quoi. Typiquement, ça le dérange pas, il

quoi. Typiquement, ça le dérange pas, il il il va pas trouver votre script est mal fichu, il se souvient pas, il est pas écrit correctement.

[grognement] La semaine dernière, mon GitLab CI, je l'ai changé mon mon petit script de d'accès à GitLab. Sauf que

lui, il avait en mémoire l'ancienne documentation. Donc à chaque fois, il

documentation. Donc à chaque fois, il allait relire le fichier, tout comprendre plusieurs fois. Et ça, ça consomme un max de tokens. Donc l'idée

derrière, en fait, c'est d'analyser tout le travail répétitif qu'il fait souvent.

Il recharge les envs de manière astronomique, il repoule le backlog.

Bref, ce qu'on appelle le toil.

Et le retry, ben ça, c'est une étape qui a échoué et qui va relancer de manière régulière. Ça, c'est de la friction. La

régulière. Ça, c'est de la friction. La

friction, c'est ce qui coûte du temps et de l'argent.

Donc l'idée, si on a commencé à monitorer la bestiole à chaque essai et qu'on injecte tout ça dans de la data, eh ben on va pouvoir faire de l'analyse en continu. Ça, c'est mes petites datas

en continu. Ça, c'est mes petites datas perso. En gros, entre le 12 mai, on est

perso. En gros, entre le 12 mai, on est passé de beaucoup trop de friction sur une semaine à quasiment plus rien où les scripts répétés sont transformés en en action. Et de l'autre côté, on est

en action. Et de l'autre côté, on est passé de 38 tickets réalisés en une semaine à 1300. Ouais, ouais, c'est pour ça que j'ai plus de tokens pour vous les présenter ce soir, mais on augmente l'autonomie.

En fait, ce qui m'intéresse surtout derrière, c'est de vous dire demandez à Claude de s'analyser lui-même, mettez-lui en place ce qu'il faut pour que vous optimisiez son flow et que vous

réduisiez son coût. Son tropique, il a aucun intérêt à à vous consommer moins de tokens, hein.

Et comment on fait pour passer sur une appli legacy ou qui était mal codée comme des ? Ça fait 3 mois que vous êtes

comme des ? Ça fait 3 mois que vous êtes dessus, comment vous mettez ça en place petit à ? Parce que comme quand moi je

petit à ? Parce que comme quand moi je reviens sur une démarche legacy, On commence par recartographier les zones chaudes. Si je vous dis ça, c'est parce

chaudes. Si je vous dis ça, c'est parce qu'on a des clients qui viennent nous voir pour faire exactement ça. Le

problème, c'est que eux n'ont même pas la connaissance fonctionnelle du bousin qu'ils ont généré.

Donc en fait, il faut déjà commencer par analyser ce que ça fait, comprendre les besoins business et ensuite en cartographie, on va venir analyser les zones chaudes, les sécuriser, les

isoler, on met en place des verrous et on peut accélérer sur les endroits sur lesquels on a déployé le filet. L'idée,

c'est la même approche que sur du Legacy sauf que là, bah il y a pas grand monde qui peut nous répondre. C'est comme si vous héritez d'une entreprise dans laquelle il y a plus personne qui travaille dedans.

OK, ça tourne tout seul.

Mon petit verdict après quelques mois, une fois qu'on a augmenté la vitesse, que ça va fonctionner en autonomie, que ça s'entretient tout seul, le bilan.

Pour moi, ce que je trouve rigolo, c'est qu'aujourd'hui le marché, il y a pas forcément le même avis, il y a des grosses entreprises qui se disent "OK, moi je vais vous proposer des agents qui surveillent les agents ou qui vont venir faire le

tout ce que je vous propose à votre place, qui va se débrouiller tout seul."

Ils vous proposent un outil de plus branché en aval.

Mon approche que je vous propose, c'est de dire "OK, si on faisait le travail d'ingénierie, mais en fait, on allait onboarder le cloud dans notre démarche en lui donnant nos process et notre manière de fonctionner."

Donc en gros, on crée une machine qui surveille la machine et ensuite qui tranche.

C'est nous. L'idée, c'est qu'en fait, on ne viendra pas nous remplacer. Je suis

pas d'accord, on ne remplacera pas l'humain faire du dev, mais par contre, on va se retrouver à industrialiser la machine pour aller de plus en plus vite, à mon sens.

Parce que pour moi, la confiance dans un projet ou dans un produit, c'est pas de la magie, ça reste de l'ingénierie.

Et maintenant, je vous invite à vous aussi à me fouiller avec moi pour me poser le maximum de questions. Ah, j'en

profite juste, je vous ai juste mis là, euh ça c'est mon site de la boîte avec des articles des fois un peu trop compliqués mais bon on s'amuse bien. Et

sur l'autre c'est mon blog perso dans lequel je raconte mes pérégrinations autour des IA. Des fois c'est un peu trop compli enfin je vous ai mis plein de gros mots mais dedans je détaille certains sujets dont je vous ai évoqués là et au grand

plaisir d'échanger autour de ça.

[applaudissements]