Dans mon article précédent, j'expliquais pourquoi les agents IA échouent au débogage sur les projets existants. Le constat était brutal : l'étude METR montre que les développeurs sont 19 % plus lents avec l'IA sur les tâches complexes.
Et le problème fondamental, c'est le manque de contexte.
Un diagnostic sans solution, c'est frustrant.
Alors j'ai cherché une réponse concrète. Et la question qui a tout changé n'est pas « comment rendre l'IA plus intelligente ? » mais plutôt : « et si le problème n'était pas l'intelligence de l'IA, mais le format dans lequel on lui fournit le contexte ? »
Anthropic le dit explicitement : « l'intelligence n'est pas le goulot d'étranglement — c'est le contexte ».
Et ChatDBG, un projet de Microsoft Research et UMass publié à FSE 2025, le prouve par les chiffres : quand on connecte un LLM à un vrai débugueur avec des données structurées, le taux de résolution passe de presque zéro à 67 % au premier essai. Avec un seul suivi supplémentaire, on atteint 85 %.
L'idée était là, sous mes yeux : construire un agent spécialisé qui trace les chemins d'exécution du code, étape par étape. Comme un débugueur d'IDE, mais dans un format conçu pour l'IA.
Pas pour l'humain.
Dans cet article, je vais vous montrer le design complet de cet agent et un vrai rapport de debug avec 16 étapes tracées sur un projet SvelteKit 5. J'expliquerai pourquoi cette approche résout le problème fondamental du contexte, et je vous donnerai un template pour créer votre propre agent débugueur.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le débugueur réinventé : conçu pour l'IA, pas pour l'humain
Ce que fait un débugueur d'IDE (et pourquoi l'IA n'en a pas)
Quand un développeur débugue, il lance un débugueur intégré à son IDE. Il pose des breakpoints, fait du step-into, du step-over, surveille les variables avec un watch, et remonte la call stack.
Ces outils sont conçus pour l'humain qui raisonne de manière spatiale et visuelle. Le développeur « voit » le flux, « navigue » dans le code, construit un modèle mental du problème en temps réel.
L'IA n'a rien d'équivalent.
Quand on demande à un agent IA de débuguer, il reçoit du code source brut et doit deviner le flux d'exécution. C'est comme demander à quelqu'un de résoudre un puzzle de 500 pièces sans avoir l'image de la boîte.
Microsoft Research confirme le problème avec Debug-gym : « les outils IA actuels ne cherchent pas d'informations supplémentaires quand les solutions échouent — ils devinent au lieu d'investiguer ».
Et pourtant, les développeurs passent la majorité de leur temps à débuguer, pas à écrire du nouveau code.
Le décalage est flagrant : on a construit des outils IA extraordinaires pour écrire du code, mais rien pour le débuguer.
Même objectif, format différent
En pratique, cela signifie que l'humain et l'IA ont besoin de la même chose : comprendre le chemin d'exécution d'une action dans le code. Mais le format idéal diffère radicalement.
L'humain a besoin d'une interface visuelle et interactive : breakpoints, step-into, watch.
L'IA a besoin de données structurées et séquentielles : un input, un output et un status à chaque étape, dans l'ordre du flux.
Le format idéal pour l'IA ressemble à un trace distribué OpenTelemetry : une séquence d'étapes avec des métadonnées structurées à chaque maillon.
L'analogie est directe : le rapport de debug est un « distributed trace » appliqué au code source plutôt qu'au runtime.
Et les résultats de ChatDBG le confirment : quand on connecte un LLM à un vrai débugueur, il atteint 67 % de résolution au premier essai. Plus de 75 000 téléchargements et une publication à FSE 2025 viennent valider l'approche.
| Aspect | Débugueur IDE (humain) | Agent débugueur (IA) |
|---|---|---|
| Interface | Visuelle, interactive | Textuelle, structurée |
| Navigation | Breakpoints, step-into | Path tracing séquentiel |
| Données | Watch variables en temps réel | Input/Output/Status par étape |
| Raisonnement | Spatial, intuitif | Séquentiel, analytique |
| Sortie | Compréhension dans la tête du dev | Rapport structuré dans le contexte |
L'architecture de l'agent frontend-debugger
Un agent read-only par design
L'erreur courante est de construire un agent qui diagnostique et corrige en même temps. C'est un piège.
Mon agent frontend-debugger utilise uniquement des outils de lecture : Read, Grep, Glob et Bash en lecture seule. Pas de Write, pas de Edit.
C'est un choix architectural délibéré, pas une limitation.
L'agent analyse, il ne corrige pas. La séparation des responsabilités est stricte : le diagnostic d'un côté, le fix de l'autre.
Pourquoi ? Parce qu'un agent qui peut modifier le code est tenté par le « fix prématuré » — il propose une correction avant d'avoir compris le problème en profondeur.
Ce design suit les patterns recommandés par Anthropic dans la documentation Claude Code : « concevez des sous-agents focalisés : chaque sous-agent doit exceller dans une tâche spécifique ». L'agent Explore intégré à Claude Code est d'ailleurs lui aussi read-only.
Le frontend-debugger pousse cette logique plus loin en se spécialisant dans le diagnostic de flux.
PubNub confirme : « les agents read-only (reviewers, auditeurs) utilisent Read, Grep, Glob — analysent sans modifier ».
Voici le frontmatter YAML réel de l'agent :
--- name: frontend-debugger description: > Use this agent to trace and document frontend execution pathways. Given a user action and route, the agent reads the config, identifies the code entry point, traces the full execution path through every intermediate step (components, props, stores, handlers, effects, config resolution), identifies any gap or breakage point, and generates a debug report. This agent analyses only — it does NOT propose or apply fixes. model: opus color: orange tools: - Read - Grep - Glob - Bash ---
Le point clé : aucun outil d'écriture n'est autorisé. L'agent ne peut pas être « tenté » de proposer un fix.
Il se concentre exclusivement sur la compréhension du flux.
Les 6 phases d'analyse
L'agent suit un pipeline séquentiel en six phases.
Google le confirme dans ses Multi-Agent Design Patterns : le pipeline séquentiel est « linéaire, déterministe, et rafraîchissamment facile à déboguer parce qu'on sait toujours exactement d'où viennent les données ».
Ce design correspond au pattern de « progressive disclosure » décrit par Lance Martin : l'agent ne charge pas tout le contexte d'un coup, il trace étape par étape.
Voici les six phases :
1. Symptom Analysis — Comprendre le symptôme rapporté.
Quel est le comportement observé vs le comportement attendu ?
Quelles actions déclenchent le problème ? L'agent structure la réponse sous forme de champs : Action, Route, Expected, Actual.
2. Config Reading — Lire la configuration de l'application.
Dans notre cas, l'application SvelteKit est config-driven : un fichier JSON est la source de vérité pour tout le comportement.
L'agent identifie les routes, les composants, les dépendances, et les sous-configurations référencées.
3. Entry Point Discovery — Trouver le point d'entrée du flux.
L'agent remonte de l'action utilisateur jusqu'au composant racine et identifie le premier maillon de la chaîne.
4. Path Tracing — Tracer le chemin d'exécution complet.
C'est la phase la plus longue.
L'agent suit le flux de données de maillon en maillon et documente chaque étape avec File:line, Input, Output et Status (OK/BROKEN/SUSPECT).
5. Gap Identification — Identifier le point de rupture.
L'agent compare les inputs attendus vs reçus à chaque étape et trouve l'endroit exact où les données se perdent ou se transforment incorrectement.
6. Debug Report — Générer le rapport structuré.
L'agent compile toutes les étapes dans un fichier Markdown sauvegardé dans docs/debug/ avec la convention de nommage {date}_{commit}_{slug}.md.
Symptom Analysis → Config Reading → Entry Point Discovery
↓
Debug Report ← Gap Identification ← Path Tracing
Le format du rapport de debug
Chaque étape du rapport suit un format standardisé. C'est cette standardisation qui fait toute la différence pour l'IA.
### Step 7 : FormBuilder reçoit la configuration du formulaire **File:** `src/lib/components/FormBuilder/FormBuilderV2.svelte:1039` **Input:** `visibleFields` from schema, `initialData = newEvent` **Output:** Each field gets `initialData` containing `startDate`, `endDate`, etc. **Status:** OK
Quatre champs. Toujours les mêmes.
File:line pour localiser précisément dans le code, Input pour les données entrantes, Output pour les données sortantes, et Status pour le verdict.
Le rapport se termine par une visual chain ASCII qui résume tout le flux en un schéma. Ce format est structurellement équivalent à un trace OpenTelemetry : une séquence de spans avec des attributs structurés.
Le rapport est sauvegardé avec une convention de nommage stricte : {date}_{commit}_{slug}.md. Par exemple : 2026-02-09_2eabca8_agenda-dateclick-to-timelinepicker-pathway.md.
Cette convention lie chaque rapport à un commit précis, ce qui crée un historique traçable.
Un rapport de debug réel : 16 étapes tracées
Le contexte du bug
Passons à la pratique. Voici un cas réel sur une application SvelteKit 5 config-driven avec un système de formulaires dynamiques.
Le bug : dans un module agenda mensuel, cliquer sur une date pour créer un événement ne transmettait pas la date sélectionnée au composant TimelinePicker imbriqué.
Le symptôme était visible : le TimelinePicker s'ouvrait systématiquement sur la date du jour, alors qu'il aurait dû afficher la date cliquée.
Ce type de bug est typique des flux config-driven. La donnée traverse de nombreux composants intermédiaires et se perd quelque part dans la chaîne.
Sans outil de traçage, trouver où la donnée disparaît revient à chercher une fuite dans une canalisation enfouie.
Les 16 étapes du chemin d'exécution
L'agent frontend-debugger a tracé le flux complet, de l'URL jusqu'au rendu final. Voici les 16 étapes condensées :
Step 1: Route resolution → config lookup [OK]
Step 2: Form schema generation → fieldCustomization [OK]
Step 3: Agenda component → rendu calendrier [OK]
Step 4: dateClick handler → newEventData créé [OK]
Step 5: updateEventsForModal → newEvent construit [OK]
Step 6: Modal → FormBuilderV2 lancé avec initialData [OK]
Step 7: FormBuilderV2 → itère sur les fields [OK]
Step 8: FormFieldV2 → TimelinePickerFieldComponent [BROKEN]
⚠ initialData non transmis au composant
Step 9: pickerInitialDate → dérivation depuis données [OK]
Step 10: Config sub-page → /agenda-vue-timeline lue [OK]
Step 11: API fetch → événements récupérés [OK]
Step 12: Embedded Agenda → rendu en mode picker [OK]
Step 13: Calendar init → initialDate dans options [OK]
Step 14: $effect → navigation date via setOption [OK]
Step 15: Resources → auto-sélection en mode picker [OK]
Step 16: Event filtering → seuls les événements du jour [OK]
Regardons trois étapes en détail pour comprendre la granularité du rapport.
L'étape 4 — le handler de clic sur la date :
### Step 4: User clicks Feb 12 — dateClick handler fires
**File:** `src/lib/components/coreLibrary/Agenda/utils/calendarHandlers.ts:209-248`
**Input:** `info.date = Date(2026-02-12)` from @event-calendar/core
**Action:** createDateClickHandler reads fieldMapping, builds newEventData:
{ startDate: "2026-02-12T09:00", endDate: "2026-02-12T10:00", ... }
**Output:** Calls openSidebarForm() + updateEventsForModal(newEventData)
**Status:** OK
L'étape 8 — le point de rupture :
### Step 8: FormFieldV2 detects timeline_picker — renders TimelinePickerFieldComponent
**File:** `src/lib/components/coreLibrary/FormBuilder/FormFieldV2.svelte:1819-1830`
**Input:** field.type === "timeline_picker" (about field), initialData = newEvent
**Action:** <TimelinePickerFieldComponent {field} {initialData} ...>
**Output:** Component receives field.timelinePicker.pageConfigUrl + initialData.startDate
**Status:** BROKEN (avant fix) → OK (après fix)
L'étape 9 — la dérivation réactive en aval :
### Step 9: pickerInitialDate derived from initialData **File:** `src/lib/components/.../TimelinePickerFieldComponent.svelte:51-63` **Input:** initialData.startDate = "2026-02-12T09:00" **Action:** $derived.by() extracts initialData["startDate"], parses new Date() **Output:** pickerInitialDate = Date(2026-02-12T09:00) **Status:** OK
Le gap identifié est net. L'étape 8 est le point de rupture : le composant FormFieldV2 ne transmettait pas la propriété initialData au composant TimelinePickerFieldComponent.
Toutes les étapes en amont (1-7) fournissaient correctement la date. Toutes les étapes en aval (9-16) fonctionnaient parfaitement si elles recevaient la donnée.
Le fix a touché trois fichiers pour ajouter le passage de initialData à travers la chaîne. Une fois le fix appliqué, les 16 étapes passent au statut OK.
La visual chain ASCII
Le rapport se termine par une visual chain qui résume tout le flux en un schéma :
URL /agenda-vue-mois
|
v [pageId]/+page.svelte ---- configPath="/agenda-vue-mois"
| resolvePageConfigWithParents() --> component="Agenda"
| convertContextsToFormSchema() + fieldCustomization
| about field gets type="timeline_picker"
|
v Agenda.svelte ---- dayGridMonth view
| User clicks Feb 12
| createDateClickHandler --> newEventData { startDate: "2026-02-12T09:00" }
| updateEventsForModal --> newEvent
| showAddEventModal = true
|
v AgendaAddEventModal.svelte
| <FormBuilderV2 schema={formSchema} initialData={newEvent}>
|
v FormBuilderV2.svelte ---- iterates visibleFields
| <FormFieldV2 field={about} initialData={newEvent}>
|
v FormFieldV2.svelte ---- field.type === "timeline_picker"
| <TimelinePickerFieldComponent field={about} initialData={newEvent}>
|
v TimelinePickerFieldComponent.svelte
| pickerInitialDate = new Date("2026-02-12T09:00")
| loadConfig() --> configStore.pages["/agenda-vue-timeline"]
| loadEventsFromApi() --> http_api_get("/eventcorestrat")
| <Agenda config={timelineConfig} pickerMode={true} initialDate={Feb 12}>
|
v Embedded Agenda.svelte ---- resourceTimelineDay view
opts.initialDate = Feb 12 (construction)
$effect: ec.setOption('date', Feb 12) (runtime)
Resources from /servicecorestrat, auto-selected
Only Feb 12 events visible (date range filter)
Ce schéma donne une vue d'ensemble instantanée.
On voit d'un coup d'oeil la profondeur du flux : sept composants traversés, des configurations imbriquées, un appel API, une dérivation réactive, et une navigation programmatique du calendrier.
C'est l'équivalent d'un Codemap (le concept popularisé par Windsurf/Cognition) mais focalisé sur un chemin de debug spécifique plutôt que sur l'ensemble du codebase.
Et surtout, c'est un artefact partageable : il documente le flux pour les futurs debugs.
La prochaine fois qu'un bug apparaîtra dans ce même chemin, le rapport existant servira de carte de référence.
Pourquoi les chemins d'exécution sont le format idéal pour l'IA
Le context engineering appliqué au debug
Anthropic définit le context engineering comme « trouver le plus petit ensemble de tokens à haute valeur qui maximise la probabilité du résultat souhaité ». Le rapport de debug est exactement cela.
Chaque étape — File:line, Input, Output, Status — contient des tokens à haute densité informationnelle. Pas de code source brut à parser, pas de fichiers entiers à scanner : uniquement l'information pertinente, structurée et séquencée.
Martin Fowler décrit le pattern de « progressive disclosure » pour les agents : au lieu de charger toutes les données en amont, l'agent découvre le contexte couche par couche.
Le frontend-debugger l'applique au debug en traçant le chemin étape par étape.
Les résultats du context engineering sont mesurables. Anthropic rapporte jusqu'à 54 % d'amélioration sur les tâches d'agents en optimisant le contexte fourni.
Et selon le rapport LangChain sur l'état de l'Agent Engineering, 89 % des organisations ont implémenté une forme d'observabilité pour leurs agents — le tracing structuré est devenu un prérequis, pas un luxe.
Le format séquentiel correspond au raisonnement de l'IA
Les LLM traitent l'information de manière séquentielle dans leur fenêtre de contexte. Un rapport de debug structuré (étape 1 → étape 2 → ... → étape 16) correspond parfaitement à ce mode de traitement.
Chaque étape est auto-contenue : File:line, Input, Output, Status. L'IA n'a pas besoin de « deviner » le contexte entre les étapes.
Tout est explicite.
Le status OK/BROKEN/SUSPECT permet un triage immédiat. L'IA peut se concentrer sur les étapes problématiques sans relire l'ensemble.
La visual chain offre une vue d'ensemble rapide sans surcharger le contexte.
Dans notre expérience, la différence est spectaculaire.
Donner du code source brut à l'IA, c'est comme lui donner une pile de pièces de puzzle sans l'image de référence. Le rapport de debug, c'est l'image de référence annotée.
L'analogie de la « carte vs territoire » résume tout : l'IA avait le territoire (le code source) mais pas la carte (le chemin d'exécution).
Le frontend-debugger crée la carte. Et avec une carte, même un agent « junior » peut identifier où le chemin est bloqué.
Guide : créez votre propre agent débugueur
Le template minimal
Voici un template générique que vous pouvez adapter à votre stack.
Il reprend les principes fondamentaux du frontend-debugger mais reste assez flexible pour fonctionner avec React, Vue, une API REST ou tout autre contexte.
---
name: debugger
description: |
Trace les chemins d'exécution du code pour diagnostiquer les bugs.
## Processus en 6 phases
1. SYMPTOM ANALYSIS : Comprendre le symptôme
- Action, Route, Expected, Actual
2. CONFIG READING : Lire la configuration
- Routes, composants, dépendances
3. ENTRY POINT DISCOVERY : Trouver le point d'entrée
- Composant racine, handler d'action
4. PATH TRACING : Tracer le chemin complet
- File:line, Input, Output, Status à chaque étape
5. GAP IDENTIFICATION : Identifier le point de rupture
- Comparer inputs attendus vs reçus
6. DEBUG REPORT : Générer le rapport
- Compiler dans docs/debug/{date}_{commit}_{slug}.md
## Format de chaque étape
### Step N : [description]
**File:** [chemin:ligne]
**Input:** [données entrantes]
**Output:** [données sortantes]
**Status:** OK | BROKEN | SUSPECT
Cet agent analyse uniquement. Il ne propose PAS de fix.
tools:
- Read
- Grep
- Glob
- Bash
disallowedTools:
- Write
- Edit
- NotebookEdit
---
Enregistrez ce fichier dans .claude/agents/debugger.md de votre projet et Claude Code le reconnaîtra comme un sous-agent invocable.
Les trois principes à respecter
Quel que soit votre stack, trois principes sont non négociables.
1. Read-only par design. L'agent ne doit pas pouvoir modifier le code.
Un agent qui diagnostique et corrige en même temps est tenté par le « fix prématuré » : il propose une correction avant d'avoir compris le problème. La séparation diagnostic/fix évite cette erreur systémique.
2. Phases séquentielles. Suivre un pipeline linéaire.
Ne pas sauter d'étapes, ne pas tenter de raccourcis.
Google confirme que le pipeline séquentiel est le pattern le plus fiable pour le debug car il garantit que chaque couche est inspectée.
3. Format structuré. Chaque étape doit contenir les mêmes champs : File, Input, Output, Status.
La standardisation permet à l'IA de comparer les étapes entre elles et d'identifier les incohérences. Un format libre nuit à la détection systématique des gaps.
Adaptations par stack
Le template est un point de départ. Selon votre stack, certaines phases méritent d'être ajustées ou enrichies :
| Stack | Adaptation suggérée |
|---|---|
| React / Next.js | Ajouter une phase « State Flow » pour tracer les hooks et le context |
| API REST | Ajouter une phase « Request/Response Mapping » pour chaque endpoint traversé |
| Base de données | Ajouter une phase « Query Trace » pour les requêtes SQL et leurs résultats |
| Microservices | Adapter la visual chain pour les appels inter-services et les timeouts |
L'essentiel n'est pas de copier le template tel quel, mais de respecter les trois principes : read-only, séquentiel, structuré. Le reste s'adapte à votre contexte.
Limites et perspectives
Ce que l'agent ne fait pas (encore)
L'honnêteté intellectuelle impose de reconnaître les limites.
L'agent opère en analyse statique : il trace le chemin en lisant le code source, pas en exécutant l'application.
Les bugs de runtime pur — race conditions, problèmes de timing, états transitoires — lui échappent partiellement. Il peut identifier les conditions qui mènent à une race condition, mais pas la prouver.
Microsoft avec Debug-gym rappelle que même les agents équipés d'outils de debug ne résolvent encore que moins de 50 % des problèmes complexes. Les outils améliorent le taux mais ne garantissent pas le résultat.
Le rapport dépend de la capacité de l'agent à lire et interpréter le code correctement. Sur des architectures très abstraites ou très dynamiques, le path tracing peut manquer des indirections.
La visual chain ASCII est utile mais reste un schéma simplificateur : les flux réels peuvent comporter des branches, des boucles, des appels asynchrones.
Les évolutions à surveiller
Plusieurs avancées convergent vers un futur où cette approche deviendra encore plus puissante.
Debug-gym ouvre la voie vers des agents qui combinent analyse statique et exécution dynamique.
Imaginez un agent qui trace le chemin dans le code source, puis exécute des tests ciblés pour valider chaque étape. La combinaison des deux approches serait redoutable.
La proposition d'intégrer le tracing OpenTelemetry dans le Model Context Protocol (MCP) pourrait créer un standard pour l'observabilité des agents.
Lance Martin note qu'« il n'y a pas de standards pour l'observabilité des agents, d'interfaces de débogage communes » — ce standard manquant pourrait bientôt émerger.
Codemaps de Windsurf/Cognition montre que la cartographie de code augmentée par l'IA devient mainstream. Le debug agent est une application spécialisée de cette tendance.
Et LADYBUG, publié à EDBT 2025, applique le tracing aux sorties des agents LLM eux-mêmes — la convergence entre debug de code et debug d'agents se dessine.
À terme, les agents pourraient générer automatiquement des rapports de debug avant chaque tentative de fix, rendant le pattern « comprendre d'abord, modifier ensuite » systématique.
Conclusion : tracer avant de corriger
Le chemin parcouru entre mes deux articles est celui d'un constat vers une solution.
L'article précédent posait le diagnostic : l'IA échoue en debug sur les projets existants parce qu'elle manque de contexte.
Cet article propose la réponse : au lieu de donner plus de contexte brut à l'IA, on lui donne du contexte structuré — un chemin d'exécution tracé étape par étape avec input, output et status à chaque maillon.
Le problème n'était pas l'intelligence de l'IA. C'était le format.
Au lieu de demander à l'IA de deviner où se situe le bug dans du code brut, on lui fournit une carte structurée du flux d'exécution.
Le résultat : l'IA passe de « je suppose que le problème est ici » à « le flux se casse à l'étape 8, voici les données manquantes ».
Ce qui fonctionne pour le debug fonctionne pour d'autres tâches : donner à l'IA des données structurées, séquentielles, avec un format standardisé.
C'est l'essence du context engineering. Anthropic le résume : « trouver le plus petit ensemble de tokens à haute valeur ».
Le template est dans l'article. Le résultat m'a surpris : le rapport de 16 étapes a identifié le bug en un seul passage là où les tentatives de correction à l'aveugle tournaient en boucle.
Essayez sur votre prochain bug, et dites-moi si vous observez la même chose.
L'ère du « comprendre d'abord, modifier ensuite » commence. Windsurf l'appelle « Fight slop ».
Moi, je l'appelle « tracer avant de corriger ». Dans les deux cas, c'est la même idée : l'IA a besoin de comprendre avant d'agir.
Qui suis-je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le coeur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Le débugueur réinventé : conçu pour l'IA, pas pour l'humain