Cerveau neuroatypique et développement : mon workflow pour rester productif

Mon cerveau fonctionne différemment. Je l'ai compris tardivement, et comme beaucoup de devs dans ce cas, j'ai d'abord vu ça comme un obstacle. Puis j'ai réalisé que cette pensée non-linéaire n'était pas un défaut — c'était un mode de fonctionnement différent. Et en freelance, cette différence est devenue un avantage.

Cet article n'est pas un guide médical. C'est un retour d'expérience concret sur les stratégies qui me permettent de livrer du code de qualité tout en travaillant avec (et non contre) ma neuroatypie.

L'hyperfocus : mon super-pouvoir (à double tranchant)

Quand un problème me passionne, je peux coder pendant 6 heures sans lever la tête. C'est l'hyperfocus — cet état de concentration intense que connaissent beaucoup de cerveaux neuroatypiques.

Sur Avistra, les sessions les plus productives sont celles où je plonge dans un problème complexe : refactorer le pipeline de sauvegarde canvas, débugger un comportement Firefox spécifique, ou implémenter un système de ports unifiés pour 53 protocoles. L'hyperfocus transforme ces tâches marathon en sprints.

Le revers : l'hyperfocus ne se commande pas. Et quand il s'arrête, le crash est réel. Ma stratégie :structurer l'environnement pour que l'hyperfocus ait un cadre — des sessions définies, des commandes de clôture, des checkpoints automatiques.

La variété comme carburant

Mon cerveau déteste la monotonie. Travailler sur le même projet, les mêmes fichiers, les mêmes patterns pendant des semaines — c'est le chemin le plus court vers le décrochage.

Ma solution en freelance : le multi-projet. Avistra (SaaS AV), CRM + Copilot pour un organisme de formation, site vitrine, des missions ponctuelles — chaque journée peut être différente. Ce qui pour d'autres serait de la dispersion est pour moi de la diversification énergétique.

En pratique, j'alterne souvent entre 2-3 projets dans la même journée. Pas par manque de focus, mais parce que chaque switch recharge ma batterie d'attention sur le projet suivant.

Concevoir pour un cerveau atypique

Le projet qui m'a le plus appris sur le sujet, c'est un Copilot neuroatypique — une app de gestion pour une formatrice au fonctionnement cognitif différent. Concevoir pour quelqu'un d'autre avec le même type de pensée non-linéaire, ça force à formaliser des intuitions.

Voici les 5 principes UX neuro-friendly que j'ai identifiés et appliqués :

Maximum 3 informations visibles — au-delà, c'est la surcharge cognitive. Bannière urgente (max 3) + calendrier + légende, point final.
La couleur avant le texte — le traitement visuel précède le cognitif. Un code couleur élimine le besoin de lire pour comprendre l'état d'une tâche.
Zéro choix requis au démarrage — des valeurs par défaut opinionnées. La vue affiche tout, pas de configuration nécessaire.
Urgences proactives — bannière rouge en haut, impossible à rater. Push plutôt que pull — le système vient à toi, pas l'inverse.
Feedback immédiat — confettis quand une tâche est terminée, toast de confirmation, barre de progression. Un cerveau neuroatypique a besoin de dopamine immédiate.

Les anti-patterns à éviter

En concevant ce Copilot, j'ai aussi identifié ce qui ne marche absolument pas pour un utilisateur neuroatypique :

Les pages blanches — un formulaire vide = paralysie. Toujours pré-remplir avec des valeurs sensées.
Les options multiples — radio buttons à 5+ choix = decision fatigue. Préférer les toggles binaires.
L'imbrication profonde — max 2 niveaux (projet → jalon). Pas de sous-sous-tâches.
Les outils surchargés — j'ai choisi Frappe Gantt (minimal) plutôt que SVAR (surcharge de features). Le bon outil est celui qui fait le minimum nécessaire.
Le feedback silencieux — si l'utilisateur fait une action et que rien ne se passe visuellement, il va re-cliquer 5 fois.

Mon workflow quotidien

Voici à quoi ressemble une journée type structurée pour ma pensée non-linéaire :

Matin (9h-12h) : deep work — les tâches complexes quand l'hyperfocus est le plus accessible. Features nouvelles, refactoring, bugs difficiles. Pas de meetings, pas de mails.
Début d'après-midi (14h-16h) : tâches variées — reviews, petits bugs, admin, emails. Le moment où la concentration longue est plus difficile = tâches courtes et variées.
Fin d'après-midi (16h-19h) : second wind — souvent un deuxième pic d'hyperfocus. Tests E2E, documentation, exploration technique.

La clé : ne pas combattre les cycles naturels. Si l'énergie est là, je code. Si elle n'est pas là, je fais des tâches de contexte faible plutôt que de forcer.

Les outils qui m'aident

Au-delà du workflow, certains outils sont devenus indispensables :

Claude Code avec sessions structurées — les commandes /open-sessionet /close-session créent un cadre. Quand je décroche et reviens 3 heures plus tard, le contexte est intact. Ça compense la mémoire de travail fluctuante.
Les quality gates automatiques — pre-commit hooks, pre-push validations, CI/CD. Mon cerveau oublie de vérifier les types ? Le pipeline le fait pour moi.
Le design system comme garde-fou — tokens de design centralisés, composants normalisés, cn() pour les classes conditionnelles. Ça élimine les micro-décisions de style qui drainent l'attention.
Zod pour la validation — définir le schéma une fois, valider partout. Pas besoin de se rappeler quels champs sont requis — c'est dans le contrat.

Transformer la contrainte en méthode

Ma neuroatypie m'a forcé à développer des systèmes que beaucoup de devs négligent : documentation rigoureuse, automatisation des tâches répétitives, feedback immédiat sur la qualité du code.

Ces systèmes ne compensent pas un déficit — ils créent un avantage. Sur Avistra, 693 sessions avec zéro perte de contexte, ce n'est pas malgré ma pensée non-linéaire. C'est grâce aux systèmes qu'elle m'a forcé à construire.

Si tu es dev et neuroatypique : arrête d'essayer de travailler "comme tout le monde". Structure ton environnement pour ton cerveau, pas contre lui. Les outils existent. Les patterns existent. Il reste juste à les assembler de la bonne façon.