Boîte à outils numérique mutualisée en autisme : Quand le terrain nous pousse à repenser la technologie

Historique du projet 

Concrètement, il s’agissait d’un portail où la communauté pouvait centraliser des outils, les documenter et les évaluer, notamment à partir d’appréciations qualitatives et de suivis d’utilisation. Ce portail était accessible sur le Web, mais aussi à l’intérieur d’une application de suivi conçue pour faciliter son usage dans la pratique. L’idée était d’utiliser ces évaluations, les données issues de la recherche et certaines approches d’IA (non générative) pour aider les milieux à repérer les outils qui semblaient les plus utiles selon leur situation. 

Illustration 1 : Interface du portail Web 

Hypothèse initiale 

L’hypothèse initiale était qu’une boîte à outils numérique mutualisée pourrait améliorer, pour les milieux éducatifs et psychosociaux, l’accès aux interventions et soutenir leur déploiement dans la pratique réelle. 

Développement par phases 

Cette hypothèse a été testée dans plusieurs contextes successifs. La première étape s’est déroulée pendant la pandémie de COVID‑19, alors qu’il y avait un besoin urgent de centraliser les outils utiles pour les personnes autistes et leurs proches. Cette phase a montré qu’il existait à la fois un besoin et un intérêt réel pour une base mutualisée d’outils. 

Une question importante persistait : une solution née en contexte d’urgence pouvait‑elle trouver sa place en dehors de ce contexte ?  

Pour y répondre, une deuxième recherche a été menée en milieu scolaire, puis une troisième dans des milieux psychosociaux et de la santé mentale plus variés. Chaque étape a permis d’identifier des limites et d’apporter des ajustements à la suivante, comme le montre l’illustration 2. 

Illustration 2 : Principaux constats de chaque étape

Évolution des conditions d’implantation 

À la suite d’un changement de partenaire, la recherche a été mise sur pause pendant environ une année, au cours de laquelle les milieux avaient profondément changé : 

• les critères d’utilisation donnés par les organisations n’étaient plus les mêmes ; 
• les exigences de conformité et de certification avaient évolué ; 
• d’autres outils avaient été intégrés, souvent peu compatibles entre eux, et de nombreuses personnes intervenantes se sentaient déjà submergées par le nombre de plateformes à gérer. 

Pour l’équipe de recherche, ce constat n’était pas confortable. Il signifiait que la solution patiemment développée ne répondait plus aux conditions d’implantation.  

Plutôt que de chercher à imposer une plateforme supplémentaire, les personnes responsables du projet l’ont orienté vers un outil intégrable aux environnements technologiques déjà utilisés par les personnes intervenantes, avec des fonctionnalités centrées sur l’usage réel (par exemple, la création d’outils numériques interactifs et un meilleur soutien au flux de travail). 

Cette décision a déplacé l’attention de l’équipe de manière durable : 

Apprentissages et impacts 

De cette trajectoire, trois apprentissages ressortent : 

• d’abord, la coconstruction ne peut pas reposer uniquement sur de bonnes intentions : elle demande un cadre clair, des attentes explicites et une gouvernance partagée par toutes les parties ; 
• ensuite, implanter une technologie en contexte psychosocial ou éducatif ne revient pas à déployer un outil, mais à introduire un changement organisationnel qui touche le temps, les routines, les obligations légales et les équilibres déjà fragiles des équipes ; 
• enfin, la qualité d’un produit ne garantit ni son adoption ni son impact ; ce qui compte, c’est sa capacité à simplifier le travail réel plutôt qu’à lui ajouter une couche supplémentaire. 

Ce dernier point entraîne une conséquence importante pour les milieux preneurs. Dans les projets technologiques, les personnes intervenantes ont parfois l’impression de ne pas être assez expertes pour juger de la pertinence d’un outil, surtout lorsqu’il est question d’IA ou de systèmes complexes. Pourtant, ce sont précisément leurs contraintes, leurs hésitations, leur fatigue ou leur difficulté à intégrer une solution qui fournissent l’information la plus utile sur sa capacité à survivre au réel. Dire « je n’ai pas le temps », « je ne vois pas comment l’utiliser » ou « cela ne s’insère pas dans notre fonctionnement » n’est pas un aveu d’incompétence ; c’est un retour essentiel pour éviter de construire des solutions convaincantes sur papier, mais peu viables dans la pratique. 

Dans un contexte où les technologies évoluent rapidement, la coconstruction technoclinique demande donc plus que de consulter les milieux : elle exige de reconnaître que leur point de vue ne vient pas après l’innovation, mais qu’il en constitue une condition de validité.