Introduction
En 2026, difficile de parler de développement sans parler d’IA. Sur TikTok et ailleurs, vous avez probablement déjà vu ces vidéos : une application créée en quelques minutes, une promesse de revenus et le fameux « commente PROMPT » pour récupérer la recette miracle.
Je comprends l’enthousiasme. Pouvoir donner vie à une idée sans savoir coder ouvre des possibilités. Mais entre générer une première version et maintenir un projet dans la durée, il reste du travail. Quand les bugs arrivent, que les besoins évoluent ou que les appels aux modèles commencent à coûter cher, il faut bien comprendre ce que l’on a construit.
Je ne suis pas contre les vibe codeurs. En revanche, je reste attaché à cette dimension presque artisanale du développement : comprendre un besoin, choisir une approche, construire, corriger et prendre soin de ce que l’on livre. Avec l’IA, ces responsabilités restent les nôtres, même quand nous n’écrivons plus chaque ligne à la main.
C’est dans cet esprit que j’utilise Claude Code. Et c’est cette pratique que je souhaite partager ici : sa place dans mon workflow de développeur, les tâches que je lui confie et le travail que je garde entre mes mains.
Claude Code ou Codex : lequel choisir ?
Alors, je vous arrête tout de suite : je n’ai pas de vainqueur universel à vous proposer. J’ai des usages, des préférences et des résultats qui varient selon les tâches. Comme dans le reste de cet article, je vous partage mon expérience.
Je ne limite d’ailleurs pas le choix à ces deux outils. Les modèles open weight méritent aussi leur place dans la discussion, tout comme Gemini. Selon la difficulté du problème et le contexte fourni, je n’ai pas forcément besoin du modèle le plus puissant pour avancer. Un besoin clair, un périmètre bien défini et du code à examiner constituent déjà une bonne base de travail.
Mais alors, lequel choisir ? Tous, évidemment ! Enfin, pas tous en même temps, ni pour leur faire écrire chacun une version de la même fonction. L’idée, c’est de ne pas s’enfermer dans un seul outil. Je peux avoir mes habitudes avec l’un et solliciter un autre quand une proposition ne me convainc pas ou que le raisonnement tourne en rond. Ce deuxième regard peut m’aider à repérer une hypothèse fragile ou à envisager une autre approche. Il reste ensuite à vérifier laquelle tient réellement dans le projet.
Claude Code occupe une place centrale dans le workflow que je présente ici. C’est donc sur lui que je vais m’attarder, sans en faire une réponse obligatoire à tous les problèmes.
Échanger dans un chat, déléguer à un agent
ChatGPT a largement contribué à démocratiser les échanges avec l’IA. Personnellement, je trouve le chat utile pour approfondir une technologie, confronter une idée ou examiner un problème sous un autre angle. Cet échange peut aider à construire un raisonnement, à condition de ne pas simplement accepter la première réponse qui semble convaincante.
Comprendre reste une partie essentielle du métier de développeur, même lorsque l’on utilise l’IA. Je veux pouvoir expliquer pourquoi une solution convient à mon projet, ce qu’elle implique et quelles sont ses limites. Le chat m’aide à creuser ces questions, tant que je prends le temps de questionner les réponses.
Avec un agent, mon attente change : je lui confie une tâche à réaliser dans un périmètre donné. Cela peut être rédiger une documentation à partir du code existant, examiner les performances d’une page ou implémenter une modification. Selon les outils et les accès dont il dispose, il peut consulter les fichiers, effectuer des changements et lancer des vérifications.
La différence tient donc surtout à ma manière de travailler : dans le chat, j’échange pour comprendre et décider ; avec un agent, je délègue une partie de l’exécution, puis j’en examine le résultat. Les deux se complètent, et une même tâche peut me faire passer de l’un à l’autre.
C’est autour de cette articulation que j’organise mon workflow. Voyons maintenant comment cela se traduit concrètement.
Le harness agentique : le cadre autour du modèle
Le terme paraît un peu barbare, mais l’idée est simple : le modèle ne travaille pas seul. Il lui faut un environnement pour consulter le projet, modifier des fichiers, exécuter des commandes et vérifier le résultat. Cet ensemble d’outils, de permissions et de mécanismes d’exécution constitue ce que l’on appelle un « harness agentique ».
C’est à ce niveau que j’ai fait mon choix avec Claude Code. Je le trouve suffisamment mature pour mon usage professionnel, avec une grande liberté pour adapter son fonctionnement à mes projets. Deux éléments m’intéressent particulièrement : les hooks et les skills.
Les hooks permettent de déclencher des contrôles à des moments précis du travail de l’agent. Par exemple, on peut vérifier une commande avant son exécution et la bloquer si elle ne respecte pas les règles définies. Empêcher un push lancé par l’agent est un cas concret : je peux lui laisser préparer les modifications tout en gardant la main sur leur envoi.
Les skills servent à formaliser une méthode de travail réutilisable. Prenons un skill dédié à Kubernetes. Vous pourriez me dire : « Mais le modèle connaît déjà Kubernetes, pourquoi lui expliquer à nouveau ? » Justement, connaître une technologie ne suffit pas à connaître ma façon de l’utiliser. Je peux préciser dans ce skill quelle documentation consulter, quelles conventions respecter, quand passer par Terraform et quelles vérifications effectuer avant de proposer une modification. J’y rassemble les procédures et les ressources propres à mon environnement, pour éviter de devoir tout réexpliquer à chaque tâche.
On peut également aller vers une organisation à plusieurs agents : un agent principal répartit le travail entre des agents spécialisés, puis rassemble leurs résultats. L’un peut examiner le code, un autre travailler sur une modification et un troisième en faire la revue. Cette répartition demande toutefois un vrai cadrage : qui fait quoi, avec quel contexte et selon quels critères de validation ?
Tout cela se teste et s’ajuste. Le workflow d’un autre développeur peut donner des idées, mais il faudra l’adapter à sa stack, à ses projets et à sa manière de travailler. Ajouter des agents ou des instructions n’améliore pas automatiquement le résultat.
C’est pour cette raison que je distingue le modèle de l’agent qui l’utilise. Le modèle apporte ses capacités de raisonnement et de génération. Le cadre détermine les outils disponibles, les actions autorisées et la manière d’exécuter le travail. L’autonomie dépend de cet ensemble, ainsi que de la latitude que je choisis de lui donner.
Plusieurs agents, chacun son espace de travail
C’est là que les choses peuvent se compliquer. Imaginez trois agents sur un même projet : l’un travaille sur le front-end, un autre sur la base de données et le troisième sur les tests. Sur le papier, les rôles sont distincts. En pratique, leurs modifications peuvent se croiser.
Un agent lance les tests pendant qu’un autre modifie une entité. Une erreur apparaît, puis disparaît au prochain lancement. Le premier cherche alors à corriger un problème provoqué par un travail encore en cours. On peut vite perdre le bénéfice de la parallélisation.
Je vois deux façons d’organiser cela : faire avancer les tâches dépendantes dans un ordre défini, en transmettant les résultats à l’étape suivante, ou donner à chaque agent un espace de travail séparé. Et souvent, combiner les deux.
Git worktree constitue une bonne base pour la seconde approche : chaque agent peut travailler sur sa branche, dans son propre répertoire. Mais ce nouvel espace ne récupère pas automatiquement tout l’environnement local. Dans un projet Symfony, le dossier vendor/, les fichiers de configuration ignorés par Git et les fichiers générés doivent être préparés séparément. Or, si un agent enquête sur une erreur dans un service Symfony, pouvoir consulter immédiatement le code des dépendances est utile. Je veux lui donner un environnement exploitable sans devoir tout reconstruire à chaque tâche.
Sur mon Mac, APFS offre une possibilité intéressante : le clonage de fichiers en copie sur écriture, notamment avec cp -cR, lorsque la source et la destination se trouvent sur le même volume APFS.
Le principe est simple : les fichiers clonés partagent initialement leurs blocs de données avec les originaux. Quand l’une des copies est modifiée, APFS stocke séparément les données nécessaires à cette modification. Cela permet de préparer une copie du projet sans dupliquer immédiatement tout le poids de ses dépendances.
Git worktree et le clonage APFS peuvent d’ailleurs se compléter : le premier organise les branches et les répertoires de travail ; le second permet de peupler ces espaces avec les dépendances locales à moindre coût de stockage initial.
Il faut cependant distinguer les fichiers du reste de l’environnement. Copier un .env conserve les mêmes paramètres de connexion : les agents peuvent donc continuer à utiliser la même base de données, le même Redis ou les mêmes services Docker. Ces ressources doivent aussi être séparées lorsque les tâches risquent de se perturber. Quant aux caches copiés, certains peuvent nécessiter une régénération dans le nouvel emplacement.
Avec cette organisation, chacun peut avancer sans modifier les fichiers sous les pieds des autres. Il reste ensuite à réunir les changements, résoudre les éventuels conflits et tester l’ensemble : l’isolation facilite le travail parallèle, elle ne remplace pas l’intégration.
Pourquoi je me suis intéressé au clonage natif sur macOS
En cherchant comment préparer des espaces de travail séparés pour mes agents, je m’étais d’abord intéressé à LayerFS. Cette recherche m’a aussi fait découvrir une possibilité déjà présente sur mon Mac : le clonage APFS en copie sur écriture, évoqué plus haut.
Pour mon besoin , disposer de plusieurs copies d’un projet Symfony avec ses dépendances, cette approche native mérite d’être examinée avant d’ajouter un outil supplémentaire.
Les graphiques présentent trois aspects de cette réflexion : le temps de préparation des espaces de travail, leur occupation du SSD et le temps d’exécution des vérifications. Les valeurs affichées sont hypothétiques : elles ne proviennent pas de tests réalisés sur ma machine et ne constituent pas un benchmark. Elles servent à illustrer un scénario de comparaison, sans établir de classement mesuré entre les solutions.
L’intérêt du clonage APFS réside dans le partage initial des blocs de données entre les copies. Il permet d’éviter de dupliquer immédiatement tout le contenu du projet, notamment ses dépendances. Cela ne signifie toutefois pas que PHPStan ou les tests deviennent plus rapides : la création de l’espace de travail et l’exécution du code sont deux sujets distincts.
Les résultats réels dépendront de la machine, du nombre de fichiers, des caches et de la manière dont PHP et les outils accèdent au projet. Une configuration utilisant Docker, une machine virtuelle ou FUSE doit donc être évaluée dans son contexte, sans lui attribuer une pénalité fixe.
Ce que je retiens de cette recherche, c’est l’intérêt de regarder les possibilités offertes par mon environnement avant de complexifier mon workflow. Sur macOS, le clonage APFS constitue une piste pour préparer ces copies de travail ; son gain réel reste à mesurer sur mon projet.
Conclusion
Ma manière de développer a changé avec les agents de codage. Je leur délègue une partie de l’exécution et je passe davantage de temps à cadrer les tâches, à examiner leurs propositions et à vérifier le résultat. Pour autant, je ne me vois pas livrer un projet professionnel en faisant confiance à l’aveugle au code produit.
Comprendre ce que l’on construit reste essentiel. C’est ce qui permet d’identifier un problème, d’en expliquer les conséquences à un client et de choisir une correction adaptée. C’est aussi ce qui permet de repérer un agent qui part dans la mauvaise direction, de revoir le découpage d’une tâche ou de décider qu’il vaut mieux reprendre la main.
Les hooks, les skills, les agents spécialisés et les espaces de travail séparés participent à cette organisation. Leur intérêt se mesure à ce qu’ils apportent au quotidien : moins d’interférences, des vérifications utiles et des changements que je peux comprendre et maintenir.
Mon workflow continue donc d’évoluer, avec l’objectif de gagner du temps tout en renforçant la fiabilité de ce que je livre. L’IA y prend une place importante, et mon jugement de développeur reste engagé dans chaque livraison.
Et vous, comment utilisez-vous les agents de codage dans vos projets ? Quelles tâches leur confiez-vous, et à quel moment reprenez-vous la main ? Je suis curieux d’échanger sur vos pratiques.