Ortholyse Goes Open Source: A French Speech-Therapy Tool, Open for the Right Reasons

Talk to French-speaking speech-language pathologists for an hour and a clear picture forms: the digital tools meant to support their daily work are either built for English, or built for the institution rather than the clinician, and in both cases they sit largely unused. We built Ortholyse to fill that gap, and the code is now public on GitHub.

The problem: a profession either tooled for English, or barely tooled at all

A speech-therapy assessment, whether for a child or an adult, rests on the analysis of a spoken sample. The clinician records fifteen to thirty minutes, transcribes the relevant passage by hand, then computes indicators such as mean length of utterance, morpheme counts, or syntactic complexity. Done manually on a half-hour session, this can easily take an hour, and the math becomes error-prone as soon as the volume grows.

The tools that exist for this purpose are almost all English-first, or designed for academic research with an adoption curve that discourages a clinician working in private practice. In the conversations we had with French clinicians, the same pattern came back: what is available is not loved, therefore not used, and the fallback is manual transcription. This is not a willingness problem from the field. It is a supply problem.

Ortholyse started as a response to that gap, focused on French-speaking practice, designed so that a clinician can install it, plug in a microphone, and start working without an IT prerequisite.

The technical choices, and what they imply

Three decisions shape the tool.

Whisper running locally for transcription. A therapy session contains patient data. Sending an audio file to a cloud service, even encrypted in transit, raises a sovereignty question that no practice should have to answer every time a session ends. Whisper runs on the clinician's machine, the transcript never leaves the desk, and the GDPR conversation becomes simple: the data stays where it was produced.

Spacy and NLTK for the linguistic analysis. The French pipeline uses fr_core_news_lg, the most complete Spacy model available for French, paired with NLTK for specific computations such as morpheme counting. This is not a small implementation detail. It is the hardest part of the project.

PySide6 as a desktop application rather than a web app. A web app would have been simpler to distribute, but it would have required either uploading audio files to a server or asking the browser to handle large models, which the machines in a typical practice cannot always carry. Going desktop keeps the work local and lets the app capture microphone input directly.

On packaging, we kept Python 3.12+, FFmpeg as a system dependency, and a standard Python installer. No auto-update, no telemetry, no account. The practice downloads, installs, uses.

What works, and what is not finished

The current version is honestly an MVP. It does four things, and it does them well.

It records and imports audio from inside the application, which saves the clinician from juggling a recorder, a transfer tool, and a separate analysis program. It runs the Whisper transcription, which is not perfect but turns the clinician's job into correcting a draft instead of typing the whole thing from scratch. The difference is one hour versus fifteen minutes. The manual correction stays synchronized with audio playback, which keeps the review fast. Finally, it computes the linguistic analysis on the corrected text and exports a PDF combining the transcript and the metrics, in a format suitable for a patient file.

That is the working part.

The missing part matters just as much. The default Spacy model gives a correct but generic analysis. Serious clinical use would need a model trained specifically on patient speech samples, ideally annotated by speech-language pathologists. Spacy is designed for that kind of fine-tuning, the architecture is ready, what is missing is the dataset. Building this corpus is a collective effort that does not fit inside a single private project.

The same goes for the everyday workflow features a specialist would expect: multi-patient management, history of past assessments, export to existing medical record formats, integration with practice software, fine-grained metric configuration per assessment. All of this is feasible, and all of it requires either time we do not have alone, or outside contributions that do not arrive while the code stays private.

Why we are opening the code now

Opening an internal tool from a company is not a communications gesture. It would be a communications gesture if we published three screenshots on LinkedIn and kept the code private. Putting the code on GitHub under an MIT license is a different move.

Ortholyse has real value for a clearly identified community, and that community cannot improve it if the code is not accessible. While it stays in a private repository, the tool depends on the spare time of a single person. Once public, it can receive contributions from clinician developers, from research linguists, from labs that already have annotated datasets. Work compounds better when it is open than when it is gated.

It is also consistent with how we operate at SolidScale. We work with business leaders on their artificial intelligence projects, and we routinely tell them not to rebuild what already exists in open source. The most credible proof that this stance is genuine is to apply it to our own tools.

There is a practical effect too. Publishing the code forces it to become readable, the choices to be documented, the rough edges to be cleaned. A tool that knows it is being watched tends to become a better tool. The cleanup work that preceded this publication turned out more valuable than expected.

What you can do with this

If you are a speech-language pathologist or work in a practice, Ortholyse is usable today for what it does: transcribing a session and computing the baseline indicators. The most valuable contribution you can offer at this stage is to use it and tell us what is missing, either by opening an issue on GitHub or by going through the project page on the site.

If you are a developer, a linguist, or a researcher in French NLP, the most interesting angle is improving the Spacy model through a more representative annotated dataset. The pipeline is ready to host a specialized model, the effort sits on building and labeling the corpus.

If you run a business and this publication caught your attention, it is probably because you watch how other teams structure their artificial intelligence projects. Ortholyse is an example of what we do internally, and a public codebase is the most honest version of our method we can show.

Explore the repo

The Ortholyse codebase is publicly available at github.com/assinscreedFC/ortholyse. The Labs Ortholyse page sums up the technical choices in a few lines. If you want to fork, open an issue, or simply understand how it is built, everything is open.

A note on the cadence

Ortholyse is not the only tool we are opening. Two other projects, Studo and AI Pricing, will follow in the coming weeks with the same approach: public code, honest documentation about what works and what does not, an explicit invitation to contribute or take inspiration. Each article will follow the same shape as this one, because the format matters less than the regularity.