Ortholyse passe en open source : un outil français de bilan orthophonique, ouvert pour de bonnes raisons

Discuter avec des orthophonistes francophones laisse une impression claire : les outils numériques de leur métier sont soit conçus pour l'anglais, soit conçus pour l'institution plutôt que pour le clinicien, et dans les deux cas ils sont peu adoptés. Nous avons construit Ortholyse pour combler ce vide, et nous publions aujourd'hui le code sur GitHub.

Le problème : un métier outillé en anglais, ou pas outillé du tout

Un bilan orthophonique adulte ou enfant repose sur l'analyse d'une production de parole. Le clinicien enregistre une séance de quinze à trente minutes, retranscrit le passage utile, puis calcule des indicateurs comme la longueur moyenne d'énoncé, le nombre de morphèmes, ou la complexité syntaxique. Fait à la main sur une séance d'une demi-heure, ce travail peut prendre une heure complète, et le calcul est sujet à erreur dès que la quantité de données augmente.

Les outils qui existent sur ce créneau sont presque tous anglophones, ou alors pensés pour la recherche universitaire avec une courbe d'adoption qui décourage le praticien en cabinet. Dans les échanges que nous avons eus avec des cliniciens français, le constat revient : ce qui est disponible n'est pas aimé, donc pas utilisé, donc le retour à la transcription manuelle est la norme. Ce n'est pas une question de mauvaise volonté du métier, c'est une question d'offre.

Ortholyse a démarré comme une réponse à ce manque, ciblée sur la pratique francophone, conçue pour qu'un clinicien puisse l'installer, brancher un micro et travailler sans cours d'informatique préalable.

Les choix techniques, et ce qu'ils impliquent

Trois décisions ont structuré l'outil.

Whisper en local pour la transcription. Une séance d'orthophonie contient des données patient. Envoyer un fichier audio à un service cloud, même chiffré en transit, pose une question de souveraineté qu'aucun cabinet ne devrait avoir à arbitrer à chaque enregistrement. Whisper tourne sur la machine du clinicien, la transcription ne quitte jamais le poste, et la consigne RGPD devient simple : les données restent là où elles sont produites.

Spacy et NLTK pour l'analyse linguistique. Le pipeline français utilise fr_core_news_lg, le modèle Spacy le plus complet pour le français, complété par NLTK pour des calculs spécifiques comme le comptage de morphèmes. Ce n'est pas un détail de mise en œuvre : c'est le cœur du sujet, et la partie la plus difficile.

PySide6 en application de bureau plutôt que web. Une application web aurait été plus simple à distribuer, mais aurait soit obligé à uploader les fichiers audio sur un serveur, soit demandé au navigateur de gérer de gros modèles, ce que les machines des cabinets ne supportent pas toujours. Le desktop garde le contrôle local et permet d'utiliser le micro de la machine directement.

Sur le packaging, nous avons gardé Python 3.12+, FFmpeg comme dépendance système, et un installeur Python standard. Pas d'auto-mise à jour, pas de télémétrie, pas de compte. Le cabinet télécharge, installe, utilise.

Ce qui marche, et ce qui n'est pas terminé

La version actuelle est honnêtement un MVP. Elle fait quatre choses, et elle les fait bien.

D'abord, l'enregistrement et l'import d'audio à l'intérieur de l'application, ce qui évite au clinicien de jongler entre un dictaphone, un logiciel de transfert et l'outil d'analyse. Ensuite, la transcription Whisper, qui n'est pas parfaite mais qui demande au clinicien une correction au lieu d'une transcription complète. C'est la différence entre une heure de travail et quinze minutes. La correction manuelle est synchronisée avec la lecture audio, ce qui rend la relecture fluide. Enfin, l'analyse linguistique sur le texte corrigé, et un export PDF qui combine la transcription et les métriques calculées dans un format présentable à un dossier patient.

Voilà pour ce qui marche.

Ce qui n'est pas là est tout aussi important à dire. Le modèle Spacy par défaut donne une analyse correcte mais générique. Pour un usage clinique sérieux, il faudrait un modèle entraîné spécifiquement sur des productions de parole patients, idéalement annotées par des orthophonistes. Spacy est précisément conçu pour ce fine-tuning, l'architecture est prête, ce qui manque c'est le dataset. Construire ce jeu de données est un travail collectif qui ne peut pas se faire dans le cadre d'un projet privé d'un seul développeur.

Il manque aussi tout l'environnement d'usage quotidien que demande un spécialiste : gestion multi-patients, historique des bilans, export vers les formats de dossier médical existants, intégration avec les logiciels de cabinet, paramétrage fin des métriques par bilan. Tout cela est faisable, et tout cela demande soit du temps que nous n'avons pas seuls, soit des contributions extérieures qui n'arrivent pas tant que le code reste privé.

Pourquoi nous ouvrons le code maintenant

Ouvrir un outil interne d'une entreprise n'est pas un acte de communication. Ce serait un acte de communication si nous publiions trois captures d'écran sur LinkedIn en gardant le code privé. Mettre le code sur GitHub avec une licence MIT relève d'autre chose.

Ortholyse a une utilité réelle pour une communauté clairement identifiée, et cette communauté ne peut pas l'améliorer si le code n'est pas accessible. Tant qu'il reste dans un dépôt privé, l'outil dépend du temps libre d'une seule personne. Une fois public, il peut recevoir des contributions de devs orthophonistes, de linguistes de laboratoire, de chercheurs qui ont déjà des datasets annotés. Le travail compound mieux quand il est ouvert que quand il est protégé.

C'est aussi cohérent avec la manière dont nous travaillons chez SolidScale. Nous accompagnons des dirigeants d'entreprise sur leurs projets d'intelligence artificielle, et nous leur recommandons régulièrement de ne pas réinventer ce qui existe déjà en open source. La meilleure preuve que cette approche est sérieuse, c'est de la pratiquer sur nos propres outils.

Enfin, il y a un effet pratique. Publier le code force à le rendre lisible, à documenter les choix, à nettoyer ce qui devait l'être. Un outil sait qu'il est observé devient un meilleur outil. Le travail de remise à niveau qui a précédé cette publication a été plus utile que prévu.

Ce que vous pouvez en faire

Si vous êtes orthophoniste ou que vous travaillez dans un cabinet, Ortholyse est utilisable dès aujourd'hui pour ce qu'il fait : transcrire une séance et calculer les indicateurs de base. La meilleure contribution que vous puissiez apporter à ce stade est de l'utiliser et de nous dire ce qui manque, soit en ouvrant une issue sur GitHub, soit en passant par la page projet sur le site.

Si vous êtes développeur, linguiste, ou chercheur en NLP français, l'angle le plus intéressant est l'amélioration du modèle Spacy via un dataset annoté plus représentatif. Le pipeline est prêt à recevoir un modèle entraîné spécifiquement, l'effort se situe sur la constitution et l'annotation du corpus.

Si vous dirigez une entreprise et que cette publication vous intéresse, c'est probablement parce que vous regardez comment d'autres équipes structurent leurs projets d'intelligence artificielle. Ortholyse est un exemple de ce que nous faisons en interne, et le code public est la version la plus honnête possible de notre méthode.

Explorer le repo

Le code d'Ortholyse est disponible publiquement sur github.com/assinscreedFC/ortholyse. La page projet Labs Ortholyse résume les choix techniques en quelques lignes. Si vous voulez forker, ouvrir une issue, ou simplement comprendre comment c'est construit, tout est ouvert.

Une note sur le rythme

Ortholyse n'est pas le seul outil que nous ouvrons. Deux autres projets, Studo et AI Pricing, suivront dans les prochaines semaines avec la même approche : code public, documentation honnête sur ce qui marche et ce qui ne marche pas, invitation explicite à contribuer ou à s'en inspirer. Chaque article suivra le même format que celui-ci, parce que le format compte moins que la régularité.