Pourquoi la compétence Claude Code i-have-adhd est-elle devenue virale ? Les développeurs doivent-ils migrer leur flux de travail en 2026

La compétence Claude Code i-have-adhd mérite un essai individuel à faible risque, mais elle ne justifie pas à elle seule une migration d’équipe ou vers le cloud en 2026. Elle améliore surtout l’ordre des réponses et la réduction des explications inutiles ; elle n’augmente pas automatiquement la capacité du modèle à concevoir, tester ou sécuriser votre code.

Cet article s’adresse aux utilisateurs de Claude Code qui veulent savoir si le format « réponse d’abord, détails ensuite » correspond à leur manière de développer. Il concerne aussi les lecteurs de l’écosystème AI Coding et les responsables de petites équipes qui envisagent de transformer une préférence personnelle en règle partagée.

Dernière mise à jour : 23 septembre 2026. Vérification effectuée à partir du dépôt public ciblé, de sa documentation et des ressources officielles Anthropic disponibles à cette date.

Ce que le dépôt i-have-adhd est réellement

Le premier piège consiste à parler de « i-have-adhd » comme s’il n’existait qu’un seul projet. Plusieurs dépôts ou compétences portant ce nom circulent dans l’écosystème Claude Code et AI Coding, avec des objectifs qui ne sont pas nécessairement identiques. Le périmètre retenu ici est le dépôt public ayghri/i-have-adhd, dont le contenu doit être relu avant toute installation : fichiers de compétence, instructions, licence et derniers changements.

Sa fonction est celle d’une règle d’interaction. Elle cherche à orienter la réponse vers les éléments immédiatement exploitables : décision prise, résultat, prochaine action, puis explication complémentaire. Cette approche peut réduire une friction bien précise : devoir parcourir une longue réponse avant de savoir quelle commande exécuter ou quel fichier modifier.

Elle ne doit toutefois pas être confondue avec quatre composants différents :

• Une compétence de style agit sur la forme de l’échange, la priorité des informations et parfois le niveau de détail.
• Une règle de projet, souvent portée par CLAUDE.md, décrit les conventions locales, les commandes de validation, l’architecture et les interdictions propres au dépôt.
• Un Agent Harness organise davantage l’exécution : outils, boucles de tâches, sous-agents, récupération d’erreurs, état et parfois contrôles d’autorisation.
• Un outil de gestion de tâches suit les tickets, les dépendances, les échéances et l’état de plusieurs travaux.

Anthropic distingue justement les usages des Skills, des règles, des hooks et des sous-agents dans sa présentation des mécanismes d’orientation de Claude Code. Cette distinction est essentielle : une réponse plus directe peut rendre une session plus agréable, mais elle ne fournit ni orchestration complète ni garantie de qualité.

Le dépôt est donc intéressant comme expérience d’interface, pas comme remplacement universel de votre méthode de développement. La popularité observée dans la communauté est un signal d’attention, non une validation officielle ni une preuve de gain en production.

À retenir : si votre problème est « je ne trouve pas la prochaine action dans une réponse trop longue », i-have-adhd peut être pertinent. Si votre problème est « le modèle oublie l’architecture, exécute mal les tests ou perd l’état d’une tâche », vous cherchez probablement une règle de projet, une mémoire mieux conçue ou un environnement d’exécution différent.

Pourquoi cette compétence attire-t-elle autant les développeurs individuels ?

Pour un développeur indépendant, la valeur ne vient pas d’une nouvelle capacité de génération. Elle vient d’une réduction du coût d’interaction. Dans une session de débogage, une réponse qui commence par le diagnostic probable, le fichier concerné et la prochaine vérification peut être plus facile à exploiter qu’une analyse progressive de plusieurs paragraphes.

Cela peut être particulièrement visible dans les projets où vous alternez entre code, documentation, tests et outils créatifs. Pour une application audio, par exemple, vous pouvez demander une modification de traitement du signal, puis vérifier un comportement dans une interface. Pour un projet vidéo ou de design, vous pouvez passer rapidement d’un script d’export à une correction d’interface. Dans ces contextes, la priorité donnée à l’action aide à ne pas perdre le fil entre plusieurs types de tâches.

Les bénéfices potentiels sont généralement les suivants :

• Décision plus visible : la réponse indique plus tôt si le problème vient d’une dépendance, d’un test ou d’une hypothèse incorrecte.
• Moins de texte périphérique : les justifications restent disponibles sans occuper la première place.
• Prochaine étape explicite : vous savez quelle commande, quel fichier ou quelle vérification demander ensuite.
• Meilleure continuité pendant une session courte : lorsque vous disposez de peu de temps, une réponse structurée facilite la reprise.

Mais ces bénéfices dépendent fortement de votre style de travail. Si vous avez surtout besoin de découper un projet en tâches, de conserver une décision pendant plusieurs sessions ou de surveiller des commandes longues, i-have-adhd ne traite pas le problème principal. Claude Code documente séparément ses options d’utilisation en ligne de commande dans sa référence officielle de la CLI. La gestion du terminal, la persistance du contexte et la sécurité des commandes doivent être évaluées à part.

Première étape : identifier la friction avant de modifier vos règles

Pendant quelques sessions, notez ce qui vous ralentit réellement :

1. Vous ne trouvez pas la réponse opérationnelle assez vite.
2. Vous devez répéter les conventions du projet.
3. Vous perdez le contexte entre deux sessions.
4. Vous ne savez pas quelles tâches sont terminées.
5. Vous devez contrôler des commandes ou des secrets exécutés à distance.

Seul le premier point correspond directement à une compétence d’ordre des réponses. Les quatre autres demandent une intervention différente. Cette séparation évite d’attribuer à i-have-adhd une amélioration de code qu’il n’est pas possible d’inférer à partir de son rôle.

Une compétence de style peut-elle améliorer la qualité du code ?

Non, pas directement. Elle peut améliorer la qualité de la collaboration entre vous et le modèle, ce qui peut indirectement faciliter la détection d’un problème. Mais elle ne modifie pas automatiquement les connaissances du modèle, la couverture des tests, la robustesse des appels d’outils ou la sécurité d’une modification.

Pour mesurer un effet réel, ne vous contentez pas d’une impression de confort. Prenez un petit ensemble de tâches représentatives :

• correction d’un défaut avec test de régression ;
• ajout d’une fonction dans un module existant ;
• refactorisation avec contrainte de compatibilité ;
• analyse d’une erreur de déploiement ;
• modification d’une interface audio, vidéo ou graphique nécessitant une vérification visuelle.

Conservez les mêmes consignes de projet, les mêmes critères de revue et un niveau comparable de difficulté. Comparez ensuite la clarté des réponses, le nombre de corrections nécessaires, les tests produits et les erreurs de compréhension. Si vous ne mesurez que la longueur des messages, vous risquez de confondre concision et qualité.

Les recommandations officielles d’Anthropic sur les instructions de contexte et les fichiers CLAUDE.md rappellent implicitement que le contexte utile doit être explicite. Une compétence de style ne remplace donc pas une documentation de projet précise.

Que doit vérifier une petite équipe avant de partager la compétence ?

Le passage du poste individuel au dépôt partagé change complètement le niveau de risque. Une préférence qui vous aide peut gêner un autre développeur, surtout si celui-ci attend des explications détaillées avant toute modification. Le danger principal n’est pas seulement la sortie « trop courte » : c’est la confusion entre instructions globales, règles du projet et Skills chargées dans la session.

Vérifiez notamment les interactions suivantes :

• Compétence partagée et préférences individuelles : une équipe doit savoir quelle règle est recommandée et laquelle reste facultative.
• i-have-adhd et CLAUDE.md : les conventions de test, de sécurité ou de style du dépôt doivent rester lisibles et prioritaires dans les décisions.
• Plusieurs Skills : deux instructions peuvent demander des structures de réponse différentes ou présenter des hypothèses incompatibles.
• Règles de revue : une sortie concise ne doit pas omettre les changements, risques et tests nécessaires à l’approbation.
• Permissions : une compétence de communication ne doit jamais être utilisée comme justification pour élargir l’accès aux fichiers, au réseau ou aux secrets.

Les conseils de sécurité associés à l’utilisation des Skills sont présentés dans la documentation Claude consacrée aux Skills. Vous devez également différencier les instructions de l’agent et celles de votre système de revue. Les deux ne poursuivent pas le même objectif.

Deuxième étape : conduire un essai réversible

Pour une petite équipe, limitez le test à un projet non critique ou à une branche dédiée. Désignez un groupe réduit de participants et définissez avant le début :

• les types de tâches acceptés ;
• les commandes interdites ;
• les critères de revue ;
• les conflits à signaler ;
• le responsable de la décision finale ;
• la procédure de suppression de la compétence.

Pendant l’essai, exigez que chaque modification conserve sa trace habituelle : diff, tests, commentaire de revue et décision d’acceptation. Si les développeurs adoptent les réponses plus courtes mais omettent des hypothèses importantes, le test est négatif, même si les sessions semblent plus rapides.

À l’inverse, si les prochaines actions sont plus faciles à repérer sans diminution de la qualité des explications, vous pouvez conserver la compétence comme option documentée. Ne la transformez pas automatiquement en standard obligatoire.

Le cloud est-il nécessaire pour un flux AI Coding plus stable ?

Le cloud répond à un problème d’environnement, pas à un problème de style de dialogue. Il devient intéressant lorsque votre poste local ne doit pas rester allumé, lorsque plusieurs personnes doivent retrouver une configuration identique ou lorsque les travaux longs doivent continuer après la fermeture de votre ordinateur.

Les bénéfices possibles sont concrets :

• Exécution persistante : une tâche de test, de compilation ou d’analyse peut continuer sans dépendre de votre poste personnel.
• Accès distant : vous pouvez reprendre une session depuis un autre emplacement ou un autre appareil.
• Environnement homogène : versions, dépendances et scripts peuvent être préparés de manière reproductible.
• Journalisation : les actions importantes peuvent être conservées selon la politique de votre équipe.
• Séparation des accès : les permissions peuvent être limitées à un projet ou à un rôle.

Pour un projet de montage vidéo, de traitement audio ou de design, cette continuité peut être utile lorsque les outils, les fichiers de travail et les scripts doivent rester disponibles à distance. Mais elle ne rend pas automatiquement le flux sûr. Une compétence copiée dans un espace distant ne transfère pas par magie les sessions, les secrets, les jetons, les autorisations, les données du projet ni les règles de conservation.

La différence entre infrastructure et méthode doit rester visible. Vous pouvez consulter la présentation de l’infrastructure de Kvmjet pour comprendre le rôle d’un environnement distant. Pour préparer une configuration, vérifiez aussi les recommandations de sécurité et d’accès dans le centre d’aide Kvmjet, puis formalisez vos propres règles de projet et de revue.

Point de contrôle : si vous ne savez pas quels secrets sont accessibles, qui peut ouvrir la session, combien de temps les journaux sont conservés et comment supprimer l’environnement, la migration cloud est prématurée, même si l’outil fonctionne techniquement.

Décider : tester, conserver ou abandonner i-have-adhd

Utilisez la liste suivante comme outil de décision. Cochez uniquement les critères réellement vérifiés ; une hypothèse ou une impression de popularité ne compte pas comme validation.

Checklist de décision

• [ ] La difficulté principale est la longueur ou l’ordre des réponses, et non l’absence de mémoire de projet.
• [ ] Les prochaines actions sont plus faciles à identifier après un essai sur des tâches réelles.
• [ ] Les règles de CLAUDE.md restent visibles et ne sont pas contredites.
• [ ] Les Skills utilisées dans le projet ne demandent pas un format incompatible.
• [ ] Les revues continuent de couvrir les fichiers modifiés, les tests et les risques.
• [ ] Aucun secret, dépôt sensible ou commande irréversible n’est exposé pendant l’essai.
• [ ] Au moins un autre utilisateur peut comprendre la configuration sans explication orale.
• [ ] La compétence peut être retirée sans modifier le code ni les permissions.
• [ ] Le besoin de cloud concerne réellement la continuité, l’accès distant ou la reproductibilité de l’environnement.
• [ ] Les conditions d’arrêt sont écrites avant la généralisation.

Interprétez ensuite le résultat avec ces branches :

• Si les deux premiers critères seulement sont validés, conservez i-have-adhd comme préférence personnelle et ne modifiez pas le standard de l’équipe.
• Si un conflit apparaît dans les règles ou les Skills, désactivez la compétence et revenez à la configuration minimale avant de poursuivre le test.
• Si les critères de revue, de retrait et d’acceptation sont tous validés, proposez une adoption facultative, avec version documentée et retour arrière prévu.
• Si la persistance ou l’accès distant répond à un besoin vérifié, évaluez ensuite un espace cloud ; ne migrez pas simplement le fichier de compétence.
• Si les sorties sont plus courtes mais que les tests ou les revues se dégradent, abandonnez la compétence.
• Si aucun gain n’est reproductible, ne conservez pas la configuration uniquement parce qu’elle est discutée dans la communauté.

Cette décision doit rester réversible. Conservez une copie des règles précédentes, notez les dépendances entre fichiers et évitez de mélanger le changement de style avec une refonte des permissions ou une migration d’infrastructure.

Vers un flux AI Coding durable, au-delà de la tendance

Une compétence comme i-have-adhd peut occuper une place utile dans une architecture plus large, à condition de ne pas lui demander davantage que ce qu’elle fournit.

• La compétence règle la manière de présenter une réponse.
• Le projet fournit les conventions, les tests, l’architecture et les limites.
• Les outils de suivi organisent les tâches et les responsabilités.
• L’espace cloud fournit continuité, accès distant et environnement contrôlé.
• La revue de code vérifie le résultat, les risques et la possibilité de retour arrière.

Cette séparation facilite aussi l’arrivée de nouveaux collaborateurs. Ils peuvent comprendre quelle règle influence l’écriture, quelle règle protège le dépôt et quelle procédure décide si un changement est acceptable. Les documents d’Anthropic sur les bonnes pratiques de vérification dans Claude Code recommandent d’ailleurs de contrôler le travail produit au lieu de considérer une sortie bien formulée comme une preuve suffisante.

Si votre flux actuel repose sur une machine locale difficile à maintenir, plusieurs problèmes restent ouverts : dépendance à un poste précis, interruption des tâches longues lorsque vous fermez l’ordinateur, environnement différent entre collaborateurs et contrôle limité de la continuité des journaux. Un environnement Mac distant peut alors offrir une base plus constante pour un essai, un projet audio ou vidéo, ou une session AI Coding temporaire. Cela ne remplace ni vos règles ni vos revues, mais peut éviter de reconstruire le poste à chaque test.

La bonne séquence est donc simple : testez d’abord la compétence seule, vérifiez les conflits avec le projet, mesurez l’acceptation par l’équipe, puis évaluez seulement si un espace cloud résout un besoin réel. Avant de déplacer un dépôt sensible, formalisez les secrets autorisés, les rôles d’accès, la conservation des journaux et la procédure de suppression de l’environnement. La migration d’un fichier de compétence n’est jamais une migration complète du flux de travail.

Questions fréquentes

Que change réellement i-have-adhd dans Claude Code ?

i-have-adhd modifie principalement la manière dont les réponses sont structurées : les décisions et les prochaines actions peuvent apparaître avant les explications secondaires. La compétence ne transforme pas le modèle en meilleur programmeur, ne remplace pas CLAUDE.md et ne fournit pas, à elle seule, une mémoire de projet, une gestion des tâches ou un contrôle renforcé des permissions.

La compétence i-have-adhd convient-elle à une équipe ?

Elle peut être testée par une équipe, mais elle ne devrait pas devenir immédiatement une règle obligatoire. Les préférences de communication diffèrent, et la compétence peut entrer en conflit avec CLAUDE.md, d’autres Skills ou les exigences de revue. Commencez par un petit groupe, comparez les sorties et prévoyez une suppression simple avant toute généralisation.

Claude Code peut-il entrer en conflit avec les règles du projet ?

Oui. Une compétence qui impose une structure de réponse ne possède pas nécessairement la priorité sur les instructions du projet, mais elle peut rendre leur interprétation moins lisible ou produire des sorties qui ne correspondent pas aux attentes de l’équipe. Vérifiez les règles chargées, testez les cas contradictoires et faites relire les changements avant de conserver la configuration.

Faut-il migrer un flux de travail AI Coding vers le cloud ?

Pas uniquement parce qu’une compétence est populaire. Le cloud devient pertinent lorsque vous avez besoin d’un environnement persistant, d’un accès distant, d’une configuration reproductible ou de journaux mieux conservés. Il ne transfère pas automatiquement les sessions, les secrets, les autorisations ni les données du projet. La migration doit donc suivre une conception de flux de travail déjà validée.