Triage des réparations : l’IA au service de l’équité

Des données réelles et des demandes fictives

La première difficulté du projet, c'est l'absence de jeu de données public sur les ordres de réparation du Territoire du Nord. L'équipe ne pouvait donc ni entraîner ni évaluer le modèle sur des demandes réelles de locataires. Elle a donc créé un an de demandes synthétiques.

En revanche, une partie des données géographiques est réelle : 70 communautés, le nombre de logements, les bases des équipes, les fermetures de routes, les pistes d'atterrissage et des données sur les délais d'intervention. Le produit distingue clairement ces deux catégories. Les demandes fictives sont indiquées comme telles dans l'interface, au lieu d'être présentées comme des interventions réellement effectuées.

Cette transparence vient de la conception du produit, pas d'une mention planquée dans une note de bas de page. Dans une démo, si l'on mélange données simulées et faits opérationnels, on peut facilement prendre des résultats de test pour des « preuves » sur le terrain. Dans un service lié au logement et à la sécurité des personnes, cette ambiguïté peut vite influencer des décisions. ReachNT rend donc visible l'origine des informations au moment même où on utilise le système.

Le raisonnement est transposable en France ou ailleurs en Europe : si un outil s'appuie sur des données artificielles, il faut le dire dans l'interface et dans les documents d'évaluation. Une mention discrète dans la documentation technique ne suffit pas si les résultats peuvent être repris par des gestionnaires ou des décideurs.

L'urgence doit décrire le défaut, pas la personne

La logique de départ est simple : la place dans la file ne doit pas dépendre de la façon dont le locataire formule sa demande. Le modèle analyse le texte du signalement et estime l'urgence du défaut. L'objectif est qu'il ne « récompense » pas quelqu'un parce qu'il a appelé plutôt que d'utiliser un formulaire, parce qu'il a écrit plus long, ou parce qu'il s'exprime dans un anglais plus maîtrisé.

Ce n'est pas seulement une question d'éthique. Si le système favorise les demandes les mieux rédigées, il transforme des différences de niveau de langue, d'accès au numérique ou de disponibilité en différences de délai de réparation. Et au passage, il risque d'installer automatiquement un biais qui existe déjà dans le processus - tout en donnant l'impression qu'il s'agit d'une décision neutre.

Sur ses tests, le modèle atteint un ROC-AUC de 0,84 sur des formulations qu'il n'a pas vues pendant l'entraînement. Ce chiffre montre une capacité correcte à classer les demandes, mais il ne permet pas de conclure « 84 % des décisions sont bonnes ». Surtout, il ne justifie pas qu'on laisse le système sans surveillance : une mesure de classement en laboratoire ne garantit pas le comportement sur des signalements réels, souvent incomplets, ambigus, et écrits dans des conditions difficiles.

Dans le dispositif complet, qui inclut l'examen humain de certains dossiers, le système identifie 99,3 % des signalements dangereux. Mais il faut lire cette statistique correctement : elle concerne le fonctionnement du dispositif dans son ensemble, pas le modèle seul. Confondre ces deux niveaux est une erreur classique. Un algorithme peut contribuer à un résultat sans en être la cause unique.

Pourquoi le score de confiance reste hors-champ

ReachNT accepte un classement « suffisant » pour ce démonstrateur, mais il se méfie de la confiance annoncée par le modèle. Quand le système indique une confiance d'au moins 90 %, il n'a raison que dans 56 % des cas. Si on affiche ce pourcentage à quelqu'un qui attend une réparation, on lui donne une impression de fiabilité qui n'est pas justifiée.

Un score de confiance peut sembler utile dans un tableau de bord : il donne une sensation de précision et facilite les comparaisons. Mais l'intérêt dépend d'un point très concret - la calibration. Quand un modèle annonce un certain niveau de certitude, ce niveau doit correspondre à sa fréquence réelle de réussite. Ici, l'écart est trop grand pour communiquer ce chiffre aux locataires.

D'où le choix produit : ne pas afficher de probabilité. À la place, ReachNT prévoit une explication en langage courant sur les raisons de l'attente. Et, en parallèle, 42 % des signalements dangereux sont transmis à une personne avant toute décision. Ces deux mécanismes répondent à deux besoins différents : expliquer pour rendre le processus lisible, et garder un garde-fou pour les cas à risque.

La leçon n'est pas « il ne faut jamais montrer des scores ». C'est plutôt celle-ci : une information ne devient pas automatiquement utile parce qu'elle est chiffrée. Si elle est mal calibrée, il faut la corriger et la valider dans un contexte réel, ou ne pas la présenter comme un indicateur fiable. Dans ce projet, penser avec les limites du modèle a semblé plus responsable que d'ajouter une interface « de confiance » qui ferait joli.

Regrouper les communautés pour réduire les trajets

Classer les réparations ne règle qu'une partie du problème. Il faut aussi organiser les déplacements pour éviter qu'une équipe parcoure des kilomètres pour une seule intervention, puis reparte sans traiter les demandes voisines.

ReachNT s'appuie sur H3, un système de tuilage géographique hexagonal développé par Uber. Il regroupe des communautés proches dans des cellules voisines, puis organise ces cellules en tournées hebdomadaires. Sur cinq années synthétiques tirées au hasard, ce partage des trajets réduit le coût estimé de 67 à 76 dollars australiens par réparation, à partir d'une base d'environ 821 dollars par intervention.

L'intérêt de H3, c'est de proposer une manière régulière de représenter l'espace et de regrouper des points. Mais une grille n'est pas le territoire. Les communautés ne sont pas des hexagones, les routes peuvent être inondées, et l'accès change selon la saison. La proximité géométrique ne garantit pas la proximité « praticable ». Le regroupement aide à planifier, sans dispenser de vérifier ce que la tournée vaut réellement sur le terrain.

Le classement et le regroupement répondent à deux objectifs différents

Le risque d'un système de mutualisation, c'est de réduire les coûts en repoussant les demandes urgentes qui s'intègrent moins facilement à une tournée. ReachNT sépare explicitement les deux décisions : le regroupement sert à économiser les déplacements, tandis que le classement par urgence fixe l'ordre des interventions à l'intérieur de la tournée.

Ce découpage évite qu'un objectif logistique écrase l'objectif de sécurité. Une réparation urgente ne doit pas passer après un défaut mineur juste parce que cela rend la tournée « moins chère ». Il reste des arbitrages - disponibilité des équipes, distances, délais. Mais le système pose une limite : l'économie de tournée ne doit pas inverser la priorité des réparations.

La planification hebdomadaire utilise un solveur CP-SAT. Sur 26 018 plans hebdomadaires, le solveur trouve une solution optimale pour 99,5 % d'entre eux, avec un temps médian de résolution de huit millisecondes. Il optimise les coûts et le nombre de jours pendant lesquels un défaut reste non résolu, sans pouvoir contourner l'ordre d'urgence défini.

Cette rapidité rend l'outil utile pour produire un brouillon de plan. Elle ne rend pas automatiquement le plan « juste ». Chaque proposition doit être validée par un coordinateur avant diffusion. Ce coordinateur peut tenir compte d'informations que le modèle ne connaît pas : état réel des routes, contraintes locales, ou changement de disponibilité des équipes.

Au final, la validation humaine n'est pas qu'un « plus ». Elle sert aussi à attribuer la responsabilité. Si un locataire demande pourquoi une intervention a attendu, on ne doit pas répondre en renvoyant à une boîte noire. Le système peut éclairer la planification, mais une personne doit pouvoir examiner le résultat et en répondre.

Le coût moyen ne raconte pas toute l'histoire

Sur une année simulée, ReachNT affiche un coût moyen d'environ 821 dollars australiens par réparation. Neuf réparations urgentes éloignées sur dix sont faites dans les trois jours. Le total pondéré des jours pendant lesquels les défauts restent en attente atteint 61 700.

À titre de comparaison, une référence moins coûteuse applique d'abord une logique de coût minimal. Elle arrive à 561 dollars par intervention. Mais, dans cette simulation, les réparations urgentes éloignées attendent en moyenne 62 jours (contre trois jours en ville) et le total pondéré des jours de défaut atteint 233 100.

La comparaison met en lumière un arbitrage que la moyenne seule peut masquer. On peut paraître « plus efficient » par réparation tout en imposant des délais disproportionnés aux communautés isolées. ReachNT coûte davantage par intervention dans le scénario étudié, mais limite cet écart. La question de gestion ne se réduit donc pas à : quel système dépense le moins ? Elle porte aussi sur : quels délais et quelles inégalités accepte-t-on en échange de cette économie ?

Ces chiffres ne prouvent pas que le même résultat apparaîtrait dans un service réel. Ils décrivent une expérience sur des demandes synthétiques et des distances planifiées. Même la « réaction » des locataires est simulée. Un modèle entraîné sur des formulations artificielles peut très bien réussir ses tests dans son univers, tout en échouant sur des signalements réels - souvent incomplets, ambigus et formulés dans des contextes difficiles.

Les validations indispensables avant un pilote

Avant de décider d'un déploiement, l'équipe met en avant trois chantiers prioritaires. D'abord, entraîner ou réentraîner le modèle sur de véritables formulations de locataires, avec les garanties de confidentialité et de gouvernance des données. Ensuite, refaire l'analyse de calibration : la confiance du modèle peut changer quand les textes viennent du terrain. Enfin, confronter la planification aux temps et conditions de déplacement réellement observés, pas aux distances « calculées » sur une carte.

Dans les territoires éloignés, l'accès saisonnier, les fermetures de routes et la disponibilité des transports peuvent rendre une tournée impossible. Un plan optimal sur le papier peut s'avérer inutilisable sur place. C'est pour ça que l'équipe envisage un pilote dans les 16 communautés rattachées au pôle de Katherine : un test dans un périmètre limité, avant toute extension.

Un déploiement responsable devrait aussi suivre des indicateurs qui ne se limitent pas au coût : délais par niveau d'urgence, écarts entre communautés, erreurs de classement, corrections humaines, réparations qui se détériorent pendant l'attente, et motifs d'annulation de tournées. L'idée est simple : repérer un système qui paraît bon « en moyenne », mais échoue de manière répétée pour un groupe ou pour une catégorie de défaut.

Pour un organisme français ou européen, le cadre juridique et opérationnel serait différent. Il faudra notamment définir les responsabilités, la gouvernance des données personnelles et les modalités de recours selon le service concerné. Le projet australien n'est pas une solution prête à copier-coller. Il sert surtout de cas concret pour poser les bonnes questions avant de confier une partie du triage à un logiciel.

L'audit qui a révélé un défaut de sécurité

Avant la démonstration, une revue contradictoire menée avec plusieurs agents d'IA a repéré un bug réel : un défaut critique lié au maintien d'un équipement médical pouvait être déclassé à partir d'une photo seule. Autrement dit, une demande classée comme impliquant un dispositif vital pouvait ensuite être requalifiée en réparation de routine après réévaluation de l'image.

Le problème touchait la règle la plus importante du système : l'urgence fixe l'ordre des réparations. La correction a été faite à trois niveaux. L'interface empêche le déclassement via ce parcours, le serveur valide la règle, et la base de données conserve la gravité initiale afin qu'une modification ultérieure ne l'efface pas silencieusement.

Cette défense en profondeur compte. Une règle de sécurité qui n'existe que dans l'interface peut être contournée par un autre client ou une requête directe. La validation côté serveur protège le traitement, et la conservation de la valeur initiale garde une trace et permet de détecter une modification. Aucun mécanisme isolé n'est parfait, mais leur combinaison réduit le risque qu'une seule faille de couche rende la règle inopérante.

La revue adversariale a ainsi trouvé un défaut que des scénarios de démonstration « normaux » n'auraient peut-être pas révélé. Pour un système de triage touchant à la santé, au logement ou à un service essentiel, les tests doivent inclure les modifications de dossier, les erreurs d'image, les changements de priorité et les tentatives de contournement des contrôles. La sécurité doit se vérifier sur les chemins de défaillance, pas seulement sur le cas nominal.

Le démonstrateur est consultable sur ReachNT et son code est disponible sur GitHub. Ces liens renvoient à un projet de démonstration, pas à un service public opérationnel.