Neuroatypies : debug d'un cerveau atypique en prod

Encore un énième sujet sur les neuroatypies et l'inclusion dans la tech ? Bon sang, virez-moi ça !
Ouais… je suis neuroatypique et je bosse dans la tech, donc techniquement je suis pile dans le thème du moment.

Mais je ne suis pas là pour vous faire un sermon sur la façon d'inclure un neuroA dans votre équipe, ni pour vous donner des conseils. Je vais vous parler de notre quotidien comme on debug du code : en analysant les comportements inattendus, les edge cases, et les workarounds qu'on met en place.

Pourquoi cette analogie ? Parce que quand on me demande d'expliquer mon TSA, je pourrais dire "je fonctionne différemment", mais ça ne vous avancerait pas. Par contre, si je vous dis "mon cerveau n'a pas de filtre par défaut sur les entrées sensorielles", là on commence à parler la même langue. C'est un peu comme expliquer pourquoi ton appli bouffe toute la RAM : le problème n'est pas l'intention, c'est l'implémentation.

Allons droit à l'objectif : qu'est-ce qu'une neuroatypie ? C'est tout simplement un fonctionnement neurologique atypique.

Quand on parle de neuroatypies, il y a tout un univers derrière : le TDA/H (trouble de l'attention, avec ou sans hyperactivité), le TSA (trouble du spectre autistique, avec ou sans déficience intellectuelle), les troubles dys (dyslexie, dyscalculie, dyspraxie, etc.) et les HPI/E (haut potentiel intellectuel et/ou émotionnel). Le cumul est autorisé !

Ce n'est jamais une maladie, car ce n'est pas une altération de l'organisme ; en revanche, elles sont reconnues (à l'exception des HPI/E purs) comme un handicap car elles limitent la participation à la vie en société.

Autre chose à prendre en compte : il y a souvent des points communs entre les différentes neuroatypies, surtout entre le TSA et le TDA/H, MAIS il y a autant de neuroatypies que de neuroatypiques. Vous pouvez comparer les difficultés de deux personnes avec un TSA et avoir un résultat très différent, au point de parfois se demander si elles souffrent effectivement du même trouble. Un peu comme deux applications écrites dans le même langage mais avec des architectures radicalement différentes.

Mon TSA a-t-il un impact sur mon boulot de développeur ? Sur l'équipe avec qui je travaille ? Sur mes collègues ? OUI. Parce que mon cerveau tourne avec une architecture différente. Même langage (humain), compilation différente (neurologie). Le résultat en prod n'est pas le même. Et d'un autre côté, notre manière de fonctionner, avec ou sans handicap, influe forcément sur l'équipe à laquelle on appartient, parce qu'elle n'est que la somme de nos individualités. Na !

Ce que vous savez sans doute déjà, mais peut-être mal…

Feature mal documentée : "Le génie intégré"

Les préjugés… En général, lorsque je dis aux gens que j'ai un TSA, ils froncent les yeux, rigolent et me lancent : « Nan mais sérieusement Véro… ». Bah oui, sérieusement. Les médias ont tenté de sensibiliser les gens à l'autisme, ils ont fait une distinction entre autistes profonds et Asperger… sauf que cette distinction n'existe plus. Et en plus, les gens étaient persuadés qu'une personne avec un Asperger était forcément super intelligente. Vous imaginez la pression ?!

- J'ai un syndrome d'Asperger…

- Ok ! Construis-moi une fusée avec cette boîte d'allumettes pour voir !

C'est un peu comme si on vous disait : "Tu codes en Python ? Alors monte-moi un modèle de ML distribué avec reconnaissance vocale en temps réel, là, maintenant." Euh… non ?

Les TSA (oui, je raccourcis les personnes…) légers à moyens n'ont en général pas de déficience intellectuelle, mais l'absence de quelque chose ne saurait signifier sa pleine puissance… faut doser un peu, les gens ! Vous pouvez très bien avoir un TSA et ne pas être le prochain Steve Jobs. Vous pouvez aussi être dev senior sans pour autant pouvoir coder les yeux fermés en assembleur.

Premier bug de perception cassé : nous ne sommes pas tous des surdoués, je ne vais pas vous coder votre application en un claquement de doigts…

Runtime error : interactions sociales

Nous ne sommes pas doués dans les interactions sociales. C'est tellement vrai pour les TSA que ça fait partie des critères de diagnostic. Ça ne veut pas dire pour autant que je vais rester dans mon coin à me balancer d'avant en arrière sans décrocher un mot. Nous sommes passés maîtres dans l'art du camouflage social. On inhibe volontairement nos difficultés et on fait l'effort de rentrer dans le moule pour s'intégrer. On peut le faire une journée, une semaine si on est en forme, un mois si on est jeune, un an si on a oublié pourquoi on a commencé… Ça demande une énergie colossale. Pourquoi ? Parce que l'on doit analyser et comprendre en permanence chaque interaction.

C'est un peu comme coder sans IDE, sans autocomplétion, vous devez vous souvenir de chaque syntaxe, chaque convention, chaque cas particulier. À chaque ligne de code.

Imaginons que vous rencontriez tout à fait par hasard un preux chevalier qui vous propose une partie de Sloubi. Sur le papier, ça peut être sympa, mais vous ne connaissez pas les règles. Donc, à chaque action dans le jeu, vous devez réfléchir à l'ensemble des règles existantes pour comprendre celle qui s'applique à ce moment ET pour anticiper la prochaine action. À la fin de la première partie, votre état de fatigue sera au même niveau que le nôtre lorsque l'on doit interagir.

Nous n'avons pas les règles ; il y a bien un moment où l'on connaîtra les règles principales, mais on ne pourra jamais connaître toutes les subtilités. On peut donc faire semblant de connaître un peu le jeu, on peut faire illusion quelques temps, mais ça ne durera pas.

Dans le boulot, ça donne des trucs marrants. Le daily devient un exercice de traduction simultanée. "Comment ça avance ?" Est-ce qu'il veut savoir si j'ai fini ? Si j'ai bloqué ? Si je respecte le sprint ? Toutes les réponses ci-dessus ? Mon cerveau tourne à plein régime pour décoder la question pendant que vous attendez ma réponse.

Deuxième bug de perception décrypté : à chaque interaction sociale, on joue une partie de Sloubi. Rejoignez la partie, qu'on s'amuse !

Exception non gérée : les émotions

Les autistes ne ressentent pas d'émotions. Le Terminator est jaloux ! Manager, chef d'équipe, je vous vois venir… vous ne pouvez pas déverser votre frustration sur un neuroA ! On peut vous donner le sentiment de ne pas ressentir d'émotions parce qu'on a du mal à les gérer et du mal à les reconnaître chez les autres. Parfois, on exprime une émotion différente de celle voulue ou attendue… Pourquoi ? Une de nos particularités est notre incapacité à filtrer les signaux ou stimuli.

Prenons un exemple pour clarifier les choses. Vous êtes chez vous, tranquillement en train de regarder un soap à la télé tout en laissant mijoter un bœuf bourguignon pour votre déjeuner. On sonne à la porte, vous ouvrez, et face à vous un Autrichien de 1,88 m pour 120 kg, habillé pour braquer le PMU du coin et qui, sans la moindre émotion, d'une voix monocorde, vous dit : « Sarah Connor ? ».

Votre premier réflexe est de penser : « Merde, encore un autiste ! » Nooooon ! Néanmoins, pendant tout ce temps, vous n'avez pas entendu votre télévision, ni senti que votre bœuf bourguignon brûlait, parce que votre cerveau a filtré le signal pour se concentrer sur l'essentiel : le Terminator prêt à défoncer votre porte. Vous n'avez pas eu besoin de vous concentrer sur le signal principal, votre cerveau s'en est occupé naturellement, en arrière-plan.

Chez un neuroA, ça n'est pas possible. Le filtrage ne se fait pas automatiquement. C'est comme si votre application loggait absolument tout en mode DEBUG en permanence. Logs d'erreur, logs d'info, logs de trace, tout au même niveau. Résultat : quand une vraie erreur critique arrive, elle est noyée dans le bruit.

Donc, face au Terminator, on a dû filtrer manuellement ! « Attends, ils ont dit quoi ?! Beverly a plaqué Sarah Connor ? Euh non… c'est pas ça. Monsieur, vous brûlez non ? » Alors oui, cette scène est bien plus intéressante que l'originale, mais on termine tué à tous les coups.

Cette absence de filtre nous oblige à analyser tout ce qui arrive, y compris par exemple des expressions faciales qui voudraient transmettre une émotion. Face à la multiplication des signaux, notre cerveau se perd et ne parvient pas à identifier une émotion. On ne comprend donc pas ce que l'autre ressent à ce moment, mais ça ne nous empêche pas de ressentir ! C'est un peu le paradoxe : on ne comprend pas ce qu'on ressent, mais on le ressent dix fois plus fort que n'importe qui d'autre.

Si au cours d’une réunion vous nous dites "ce n'est pas grave" avec un sourire crispé. Notre cerveau capte : votre visage (signal 1), vos mots (signal 2), votre intonation (signal 3), le silence gênant de l'équipe (signal 4), et essaie de tout parser en parallèle sans savoir quel signal prioriser. Résultat : on opine du chef en ayant aucune idée si c'est vraiment "pas grave" ou si on vient de planter la prod.

Troisième bug à terre : nous avons des émotions que nous exprimons mal, on ne comprend donc pas les vôtres, donc on a besoin de feedback clairs (zut alors ! j'ai donné un conseil…).

Les fonctionnalités cachées des neuroA

Il n'est plus question ici de préjugés, mais plutôt de la face cachée des neuroA, ce que la doc ne dit pas. Les edge cases du cerveau atypique, si vous préférez.

Je sais qu'à la lecture, certains d'entre vous pourraient être tentés de se dire qu'ils vivent la même chose, que ce n'est pas propre aux neuroA. Vous n'avez pas tout à fait tort, ce qui fait la différence, c'est le niveau de sévérité.

Bug critique : le temps qui nous échappe

La première difficulté qui me vient en tête lorsque je pense à ma journée de travail, c'est justement cette journée. Qui dit « journée », dit notion de temps. Chez les neuroA, le temps ne s'écoule pas de la même manière, il n'est pas appréhendé de la même manière. J'ai parfois le sentiment d'être le fruit d'une expérience de laboratoire d'Albert Einstein et Étienne Klein…

- Le temps est relatif ! Regarde comme il s'écoule lentement face à la résolution de ce ticket ! C'est tellement beau…

- Ok, mais es-tu sûr que ce temps existe ?

Beaucoup de TSA et TDA/H perçoivent le temps différemment parce que leur cerveau intègre plus lentement (ou différemment) les informations sensorielles et attentionnelles qui servent de "boussole temporelle". Ça fonctionne bien pour certaines tâches simples (rythme, intervalles), mais ça se complique dès qu'il faut anticiper, organiser ou estimer la durée réelle d'un événement. Stress, surcharge et hyperfocus peuvent alors étirer ou compresser la sensation du temps.

Ça peut se traduire par ce qui semble être de la procrastination ou, au contraire, de l'impatience, alors que ça n'est qu'une temporalité différente.

Essayons de se représenter les choses. Nous sommes le 1er septembre, la période estivale est terminée, la rentrée arrive rapidement. Deux repères temporels clairs, je sais où j'en suis. Une fois la rentrée passée, je n'ai plus aucun repère fixe jusqu'à la Toussaint. Ensuite vient novembre (avec mon anniversaire), puis Noël, puis mon séjour de janvier à Disneyland, puis Pâques…

Bref : je navigue de balise en balise, et le reste du temps, tout est flou.

Ces repères sont ma façon de gérer le temps. Je n'ai donc que quelques grandes périodes comme référence. L'avantage, c'est que je vieillis moins vite… d'ailleurs je ne sais jamais mon âge, je le recalcule systématiquement. J'ai dû avoir 38 ans pendant pas loin de 3 ans !

Mes journées sont aussi découpées de façon grossière, avec les 3 repas ; si j'en saute un, je raccourcis mon temps journalier. Je suis incapable de dire ce que j'ai fait dans la semaine, tel jour à telle heure. Remplir un CRA dans ces conditions relève de l'exploit, croyez-moi !

N'oublions pas mon exercice préféré … le chiffrage ! Comment peut-on prévoir la durée moyenne pour effectuer telle ou telle tâche quand on n’a pas de notion de temps ? Corriger cette faute de frappe sur l’interface ? Bien sûr ! Une demie-journée !

Première fonctionnalité cachée : une notion du temps toute relative, voire inexistante.

Overflow de la pile d'exécution : les troubles de la fonction exécutive

On a parlé de procrastination, donc c'est le moment parfait pour sortir LA fonctionnalité cachée la plus pointue du cerveau neuroA. Celle qui vous fait comprendre l'adage « Pourquoi faire simple quand on peut faire compliqué ? » : les troubles de la fonction exécutive.

En gros, la fonction exécutive, c'est la capacité du cerveau à organiser, planifier et exécuter des actions de manière fluide et adaptée. Chez un neuroA, c'est comme si le chef d'orchestre était absent ou complètement débordé. Les musiciens (nos différentes capacités cognitives) sont là, mais personne ne coordonne l'ensemble. Résultat : on sait ce qu'on doit faire, mais on ne sait pas par où commencer, dans quel ordre, ni comment s'y prendre.

En dev, c'est particulièrement vicieux. Prenons une User Story simple : "L'utilisateur doit pouvoir s'inscrire facilement".

Mon cerveau neuroA décompose instantanément :

• Quel formulaire ? Email + mot de passe ? OAuth ? SSO ?
• Validation côté front ou back ?
• Confirmation par email ?
• Si l'email existe déjà, on fait quoi ?
• Hash du password : quel algo ? bcrypt ? argon2 ?
• RGPD : on stocke quoi exactement ?
• Message d'erreur : explicite ou vague pour la sécu ?
• Tests unitaires : combien de cas ?
• Et si l'API tombe pendant l'inscription ?
• On envoie l'email avant ou après l'insertion en base ?
• Gestion des transactions ?
• Rollback si échec d'envoi d'email ?

Vous voyez le problème ? Vous, vous voyez une feature. Nous, on voit 47 décisions à prendre avant même d'écrire la première ligne de code. Et tant qu’on n’a pas clarifié ces 47 points, on ne peut pas commencer. Ça s'appelle la paralysie exécutive. C'est un peu comme un algorithme récursif qui n'aurait pas de condition d'arrêt : notre cerveau boucle sur l'analyse sans jamais atteindre l'exécution.

Deuxième manifestation : L'initiation d'une tâche. Même quand on sait exactement ce qu’on doit faire, refactoriser une méthode, écrire des tests, notre cerveau refuse de lancer le processus. Ce n'est pas de la flemme. C'est littéralement un blocage neurologique. Il nous faut un trigger externe (deadline imminente, quelqu'un qui nous poke, ou un état émotionnel particulier) pour que le "play" se lance enfin.

Troisième manifestation : La gestion des interruptions. Si on est en plein code et qu'on nous interrompt pour une question, il nous faut entre 15 et 45 minutes pour retrouver notre état mental d'avant l'interruption. Ce n'est pas juste "reprendre où on en était" : c'est recharger toute la stack en mémoire, tous les contextes, toutes les variables, tous les "pourquoi j'ai fait ça comme ça".

Un context switch qui coûte 30 minutes de latence, en gros.

Et pour parfaire le tableau : changer de tâche, même volontairement, c'est éprouvant. Passer de "coder une feature" à "répondre à un mail" puis revenir au code, c'est trois lancements de VM différentes avec rechargement complet du contexte à chaque fois.

Deuxième fonctionnalité cachée : nous avons un CPU monothread avec un temps de context switch démentiel.

Input overload : les hypersensibilités sensorielles

On l'a un peu abordé plus tôt, mais approfondissons. L'hypersensibilité sensorielle, c'est quand vos sens captent TOUT, sans filtrage, à intensité maximale. C'est comme un micro qui capte aussi bien la voix que le bruit du ventilo, des pas dans le couloir, de la circulation dehors, et du frigo qui ronronne au fond.

Comme notre cerveau ne filtre pas les signaux comme un cerveau typique, tout peut débarquer trop fort, trop faible, trop d'un coup. Un simple bruit de fond peut être agressif, alors qu'une grande claque… peut ne rien provoquer. (Évitons les tests en conditions réelles, merci.)

Pour reprendre l'analogie informatique : imaginez une application qui écouterait tous les événements système sans aucun debounce, throttle, ou filtre. Chaque mouvement de souris, chaque touche pressée, chaque changement de pixel à l'écran déclenche un traitement. En 10 secondes, votre CPU est à genoux et il doit faire des choix : tout couper (hyposensibilité) ou tout laisser passer (hypersensibilité).

Et c'est là que les choses deviennent sportives. Imaginez vous dans une salle de cinéma IMAX : son énorme, écran gigantesque, lumières agressives. Votre cerveau doit forcément court-circuiter tout le reste. À la sortie, vous êtes rincés (et si c'est un Nolan, vidés).

Maintenant, remplacez la salle IMAX par un open space, les explosions par les bruits de claviers et de conversation, les feux d'artifice par les néons, et vous avez une journée classique pour un neuroA sensible au son ou à la lumière.

Est-ce que vous seriez productifs à bosser dans un cinéma ? Voilà.

Troisième fonctionnalité cachée : nos capteurs sont réglés sur "sensibilité maximale" par défaut, sans réglage possible.

Parsing error : l'implicite, notre ennemi

Ah, l'implicite. Ce truc qui coule de source pour tout le monde sauf pour nous. L'implicite, c'est tout ce qui n'est pas dit mais qui est "évident" pour les autres. Les sous-entendus, les conventions sociales non écrites, les attentes tacites. Pour un neuroA, c'est du code commenté uniquement dans la tête du développeur précédent. Cette fois-ci, ça concerne principalement les TSA, les autres neuroA sont plutôt épargnés.

En gros, on décode le monde autrement, en privilégiant la clarté et la logique au détriment des sous-entendus.

Prenons quelques-unes de mes expériences. La dernière en date concerne les paroles d'une chanson que vous ne connaissez probablement pas : « La neige » de Michel Sardou.

La première phrase est : « Un musicien assassinait Mozart dans un café de Varsovie ». Pendant 47 ans, j'ai cherché ce que Mozart foutait à Varsovie et pourquoi un type le tuait dans un café. J'y voyais un anachronisme historique énorme.

Puis, il y a quelques semaines, miracle :

• personne n'a tué Mozart
• le musicien jouait du Mozart, sans doute mal
• mon cerveau s'est foutu de moi pendant 47 ans

A l’annonce de ma découverte, mes sœurs ont pleuré de rire. Moi aussi.

Entrons un peu plus dans le concret. Parce que l'implicite, c'est drôle en chanson, beaucoup moins au boulot. Imaginez !

User Story floue : _"L'utilisateur doit pouvoir s'inscrire facilement." _Facilement comment ? Avec confirmation mail ? Validation en temps réel ? Gestion des erreurs comment ? Feedback utilisateur sous quelle forme ?

Documentation technique incomplète : "Utilisez la méthode init() pour initialiser le module." Ok mais avec quels paramètres ? Dans quel ordre ? Y'a des prérequis ? Des dépendances ? Des effets de bord ? Sans ces infos, on ne peut pas commencer. Vous sentez poindre la paralysie exécutive ? Moi aussi.

Code review cryptique : "Cette approche n'est pas optimale." Merci, mais optimale comment ? Performance ? Maintenabilité ? Lisibilité ? Sécurité ? Mémoire ? Sans précision, on part dans une spirale d'hypothèses qui nous bouffe des heures.

Spec produit vague : "On veut quelque chose d'intuitif." Intuitif pour qui ? Basé sur quelles conventions ? Quel benchmark ? Quels retours utilisateurs ? "Intuitif" n'est pas une spec, c'est un vœu pieux.

Message Teams ambigu : "On peut en parler quand t'as 5 minutes ?" Est-ce urgent ? Bloquant ? Simple question ? Gros problème ? Notre cerveau génère 12 scénarios catastrophes avant même de répondre "ok".

Quatrième fonctionnalité cachée : l'implicite, c'est non ! Donnez-nous des specs claires

Bonus track : la fatigue invisible et les "fausses neuroA"

Un background thread permanent : la fatigue invisible

Quand on parle de fatigue pour un neuroA, on ne parle pas du manque de sommeil ou d'une journée de réunions.

On parle d'une fatigue d'arrière-plan, une énergie qui s'évapore parce qu'on fait tourner des process que vous n'avez même pas conscience d'exécuter :

• analyser les signaux sensoriels en continu,
• compenser les manques d'implicite,
• découper mentalement chaque tâche,
• anticiper les surprises,
• masquer nos réactions quand on est en société,
• rester "dans le cadre" toute la journée.

Ce n'est pas de la fragilité : c'est juste plus de calculs en parallèle, plus souvent. Comme si le cerveau était en mode "haute performance" en continu, avec un CPU qui tourne à 80% de charge même au repos.

En fin de journée, même si on a "que" codé, on est aussi crevé que si on avait couru un marathon. Parce que pendant qu’on codait, on filtrait aussi les bruits, décodait les messages Teams ambigus, gérait les interruptions, rechargeait le contexte après chaque distraction, et on tentait de rester concentré malgré les 47 stimuli sensoriels parasites.

On ne s'en plaint pas. Il faut juste savoir que ça fait partie du package.

Type confusion : l'usage abusif des mots "autiste", "TDAH", "dyslexique"

Celle-là, c'est mon coup de cœur pédagogique, pas un coup de gueule.

Vous avez déjà entendu, au détour d'une phrase :

« On n'est pas autistes ! On a bien compris que cette réforme ne passait pas ! »

ou

« J'ai fait cinq fautes, je suis dyslexique haha »

ou encore

« Ah bah moi aussi je suis un peu TDAH, j'arrive pas à me concentrer le lundi. »

Le problème n'est pas l'humour : c'est que ça n'explique rien. Et surtout : ça n'a rien à voir avec ce qu'est réellement une neuroatypie.

Être dyslexique, ce n'est pas "faire des fautes". C'est un trouble du traitement du langage écrit : identifier les sons, associer les lettres, automatiser la lecture, organiser l'écrit… Ce sont des mécanismes cognitifs précis, mesurables, qui n'ont pas grand-chose à voir avec une faute de frappe.

Être autiste, ce n'est pas "être rigide". Être TDAH, ce n'est pas "avoir du mal à se concentrer le lundi".

Ce sont des profils neurodéveloppementaux complets, avec des avantages, des contraintes, des adaptations, et de vrais handicaps.

Donc, quand j'entends ces phrases-là, je me dis juste : "On ne parle pas de la même chose". Pas de reproche, enfin presque pas. Juste un rappel : on ne réduit pas un cerveau à un trait de caractère. Et on ne compare pas un incident mineur à une architecture système.

Et pour conclure…

Voilà.

Je vous ai fait un petit tour guidé dans un cerveau neuroA :

• le temps qui s'étire ou disparaît,
• les tâches simples qui mutent en casse-tête,
• les sens qui jouent les DJ en IMAX,
• l'implicite qui nous regarde en coin,
• la fatigue en tâche de fond,
• et les mots qu'on aimerait garder pour ce qu'ils désignent vraiment.

Rien de tout ça n'a vocation à vous culpabiliser ou à vous donner un manuel "comment parler à un TSA". Il n'y a pas de mode d'emploi, pas de recette magique. Juste une réalité : on ne fonctionne pas pareil, et ce n'est ni mieux, ni moins bien.

C'est différent. Point.

Si vous devez retenir quelque chose, c'est que :

• nos réactions ne sont pas de la mauvaise volonté,
• nos difficultés ne sont pas un choix,
• et nos forces ne sont pas des super-pouvoirs.

On code, on bosse, on rit, on galère et on avance comme vous, avec un câblage un peu personnalisé, voilà tout. Une architecture différente, mais qui compile quand même.

Et pour ceux qui se demandent encore pourquoi tant de neuroA dans la tech : parce que le code, contrairement aux humains, ne fait pas d'implicite. Soit ça compile, soit ça plante. Les règles sont claires, documentées, testables. Un langage de programmation ne vous juge pas si vous mettez 30 secondes à répondre.

Le télétravail a aussi aidé : casque antibruit, environnement contrôlé, horaires flexibles, moins d'interactions sociales non structurées.

Mais ça ne fait pas de nous des mutants faits pour la tech. On a juste trouvé un environnement où certains de nos points forts (logique, obsession du détail, hyperfocus) sont valorisés, et où certaines de nos difficultés (interactions, temps, sensorialité) peuvent être contournées avec les bons outils.

Merci d'avoir suivi ce petit voyage dans un cerveau qui debug en permanence.

Aurais-je oublié de vous dire que nous avions également une manie certaine de parler pendant des heures des sujets qui nous intéressent ? Ça rend la synthèse difficile, vous l'aurez remarqué !