Calculer une dose en situation de crise : ce que la rapidité change à l’architecture

Notre réflexe, quand un client nous parle de simulation physique, c'est d'aller vers la précision. Modèles riches, validation fine, comparables à la littérature. C'est le bon réflexe en recherche. En gestion de crise radiologique, nous avons dû l'oublier.

Le scénario type : une source repérée dans l'espace public (bloc rocheux, produit abandonné, pièce accessible), des personnes exposées, des médecins qui doivent orienter les victimes vers la bonne filière de soins. Pas dans trois jours. En quelques heures. Les outils dosimétriques de référence, ceux que nous connaissons bien côté simulation, peuvent eux-mêmes demander plusieurs heures de calcul par scénario. En cellule de crise, ce décalage n'est pas un détail technique : c'est un blocage médical.

La bonne réponse scientifique, arrivée trop tard, est une mauvaise réponse. En crise, le délai n'ajuste pas un paramètre : il redessine l'architecture.

C'est ce que nous avons appris en construisant SEED avec une organisation de gestion de crise (nous restons volontairement discrets sur son identité ; voir la fiche projet). Pas un outil de recherche porté en urgence : un autre outil, avec d'autres compromis.

Ce qu'on croyait devoir livrer

Au départ, la tentation est évidente : reprendre une chaîne de calcul « sérieuse », celle qui produit des résultats défendables devant un comité d'experts, et l'accélérer un peu. Moins de mailles, moins de secondaires, un parallélisme plus agressif.

Sauf que « un peu plus vite » ne suffit pas quand l'enjeu est le tri des victimes. Il fallait accepter autre chose : des modèles volontairement simplifiés, des résultats présentés comme des ordres de grandeur orientés décision, pas comme une publication. Assez fiables pour classer les personnes exposées ; pas assez fins pour trancher au centigray près. Psychologiquement, ce n'est pas facile pour des profils formés à la rigueur. C'est pourtant le cœur du métier en crise.

La scène compte autant que le moteur

Une dose ne se calcule pas dans le vide. Il faut d'abord décrire la scène : pièce, meubles, positions des personnes, emplacement de la source. En urgence, cette description se fait avec des informations incomplètes, sous pression, par des médecins qui ne sont pas des modélisateurs 3D.

Nous avons longtemps sous-estimé cette étape. On peut avoir le meilleur moteur de simulation du monde : si la géométrie met une heure à se construire, le projet échoue autrement. Et si l'utilisateur enchaîne plusieurs scènes dans la même cellule de crise, le problème n'est pas seulement de modéliser vite une pièce : c'est aussi de passer de l'une à l'autre sans temps mort. SEED a demandé autant d'attention à la modélisation rapide qu'au calcul lui-même : objets prêts à l'emploi, navigation lisible, coupes pour se repérer dans le volume sans se perdre. Des repères empruntés à l'imagerie médicale (scanners, IRM), pas par esthétique, mais parce que les utilisateurs les connaissent déjà.

Même logique pour lire les résultats : une dose globale par victime ne suffisait pas. Il fallait voir si l'exposition dominait à la tête, au tronc ou aux membres. Là encore, des coupes orthogonales plutôt qu'un nouveau langage visuel à apprendre en pleine tension.

Trois tensions

Sur le papier, le projet ressemble à un assemblage technique. Sur le terrain, c'est surtout un exercice d'arbitrage permanent.

• L'urgence pousse à couper, simplifier, enlever tout ce qui n'aide pas la décision immédiate ; la fiabilité reste non négociable (un bug en cellule de crise, ce n'est pas un incident mineur).
• La physique exige des briques lourdes (simulation type Geant4, chaîne GATE), avec des temps de calcul difficiles à dompter.
• L'usage réel exige une interface 3D claire pour des non-ingénieurs, des transitions fluides entre scènes, et du temps de design pour ne pas sacrifier l'un à l'autre.

Chaque couche, isolée, est légitime. Ensemble, elles tirent le produit dans des directions opposées. L'architecture gagnante n'a pas été la plus « propre » sur un schéma : c'est celle qui a permis d'itérer vite, de tester en conditions réalistes, et de ne pas laisser la complexité scientifique déborder sur l'écran du médecin.

Ce qu'on a failli rater

Trois erreurs nous guettaient.

La première : croire que le logiciel suffit. Une fois SEED en place, il est apparu que le temps de réponse dépendait aussi fortement de la station de calcul. Nous avons accompagné le client dans le dimensionnement de la machine, bien après les premières maquettes. Architecture logicielle et architecture matérielle se répondent ; livrer l'un sans penser l'autre, c'est laisser une part du pari sur la table.

La seconde : laisser l'équipe « science » et l'équipe « interface » avancer en silos. Le sujet exigeait des physiciens capables de valider les ordres de grandeur, et des profils orientés design/3D capables de rendre une scène complexe immédiatement lisible. Nous avons dû les faire travailler dans le même environnement numérique : sans cette dualité au même endroit, le projet aurait basculé vers un outil de recherche impeccable mais inutilisable, ou une belle coque sans crédibilité dosimétrique.

La troisième, plus insidieuse : optimiser chaque scène isolément en oubliant la volumétrie d'usage. En crise, les utilisateurs ne restent pas dans une seule modélisation : ils comparent, reviennent, en ouvrent d'autres. Nous avions tendance à accepter de longs temps de chargement pour garantir, une fois dedans, une expérience 3D impeccable. C'était le mauvais arbitrage. Quand on bascule d'une scène à l'autre dix fois dans la même cellule, la fluidité du passage compte autant que la qualité du séjour. Nous avons dû pivoter : alléger les transitions, parfois au détriment de raffinements internes à chaque scène. En usage réel, personne ne remercie une belle scène difficile à atteindre.

Ce que la rapidité change à l'architecture

SEED est aujourd'hui un outil opérationnel dans l'arsenal de gestion de crise de l'organisation pour laquelle nous l'avons construit (référence SEED). Pour Improba, la leçon dépasse ce projet.

Quand le délai est contraint, on ne « optimise » pas un logiciel de recherche ; on en conçoit un autre, avec d'autres critères de succès, d'autres interfaces, d'autres compromis assumés. La meilleure architecture n'est pas la plus élégante sur un schéma. C'est celle qui permet, face à une scène inédite, de modéliser, basculer entre scénarios, calculer, lire et décider avant que la fenêtre d'action ne se referme.

C'est une leçon que nous retrouvons ailleurs, sur des sujets moins spectaculaires mais structurants : la contrainte de temps n'est pas un paramètre perf à graver en fin de backlog. C'est souvent le premier input du design.