NovaNote

Le problème

Quand les LLM sont apparus, ils ont ouvert un océan de possibilités pour les processus textuels. L’un des cas d’usage à la valeur ajoutée la plus évidente était de combiner la technologie déjà existante de Speech-to-Text (STT) avec la puissance de la génération de texte pour produire automatiquement des comptes rendus de réunions à partir d’enregistrements audio.

Lors de mon expérience chez Novatix, nous avons organisé un atelier avec des cadres dirigeants et parties prenantes clés d’une institution suisse de prévoyance et d’assurance et avons identifié un processus inefficace : le fait de produire des comptes rendus détaillés de longues assemblées générales (des séances de quatre à cinq heures !), juridiquement et organisationnellement sensibles, devant capturer les interventions de chaque participant, les décisions de vote et les résolutions. Le processus existant prenait plusieurs heures, s’étalant souvent sur des jours ou des semaines de travail et donnait encore des résultats incohérents.

Le plan initial était de construire la solution sur Microsoft Power Apps pour s’intégrer dans leur écosystème Microsoft 365 existant. Nous avons rapidement abandonné cette approche après avoir heurté une limitation : la limite de téléversement de 15 Mo de la plateforme la rendait inutilisable pour des enregistrements audio de plusieurs heures. En outre, l’expérience développeur sur Power Apps n’est pas idéale, donc la quitter a été un choix plutôt facile. Cette contrainte nous a forcés à construire quelque chose sur mesure, ce qui s’est avéré être la bonne décision : ce qui avait commencé comme un projet mono-client a mûri pour devenir l’une des solutions phares de Novatix, désormais déployée en production chez plus de 30 clients.

La tâche à accomplir exigeait bien plus qu’une simple transcription. Les assemblées générales sont des procédures juridiques structurées. Les comptes rendus doivent attribuer chaque intervention au bon orateur, préserver le fil logique des débats, refléter les décisions avec précision et être formatés selon les conventions de l’organisation. Les outils de transcription standards ne gèrent pas l’attribution des locuteurs avec cette fidélité. Les IA preneurs de notes généralistes manquent de la configurabilité nécessaire pour respecter le workflow, le vocabulaire et les exigences de conformité de chaque client.

Des contraintes supplémentaires ont façonné l’architecture :

• Résidence des données : La plupart des clients exigeaient que tout le traitement reste en Suisse ou dans l’UE, ce qui imposait que la sélection des modèles et de l’infrastructure soit configurable au niveau du déploiement.
• Diversité des déploiements : Les clients allaient du cloud Azure à des installations on-premises sur OpenStack chez InfoManiak (un fournisseur de cloud souverain suisse), nécessitant une infrastructure agnostique du cloud.
• Qualité audio variable : Les enregistrements allaient de configurations haute qualité en salle de réunion à des enregistrements Teams compressés.
• Adoption utilisateur : L’outil devait être utilisable par du personnel non technique, avec un minimum de friction et un support multilingue.

Mon rôle

En tant que développeur principal et architecte d’une équipe de sept personnes, j’ai porté la vision technique de bout en bout et supervisé chaque fonctionnalité significative, décision architecturale et intégration. Voici certaines de mes responsabilités :

• Conception de l’architecture système globale : API multi-tenant, pipeline de tâches asynchrones, couches d’abstraction des fournisseurs et stockage agnostique du cloud
• Création de la stratégie d’intégration STT et LLM, incluant la logique de fallback et le routage des modèles par tâche
• Supervision de la conception de l’infrastructure (Terraform sur Azure, Docker Compose, packaging de déploiement multi-environnement)
• Développement du modèle de données multi-tenant et du système de contrôle d’accès par organisation/équipe
• Révision et approbation de toutes les pull requests majeures et direction de la croissance technique de l’équipe tout au long du projet
• Tenue d’un backlog à jour, priorisation et délégation des tâches au sein de l’équipe via des réunions récurrentes de type sprint
• Pilotage de l’évolution du produit, d’un projet mono-client à une solution réutilisable et commercialisable chez Novatix

Approche technique

De l’enregistrement audio au compte rendu prêt à partager

Pour passer du fichier audio initial au document final prêt à être partagé avec les collègues, NovaNote était composé de divers workflows et processus, certains entièrement autonomes et d’autres nécessitant une vérification humaine.

1. Abstraction des fournisseurs STT avec fallback

La transcription est la première étape et la plus critique. Plutôt que de s’engager sur un seul fournisseur de Speech-to-Text, nous avons conçu un système qui fait abstraction de quatre fournisseurs : Speechmatics, Azure Speech (modes standard et rapide) et Gladia. Nous avions également un benchmark interne pour comparer les modèles STT non seulement sur le Word Error Rate (le « golden standard » des modèles STT), mais aussi sur la précision de la diarisation, c’est-à-dire l’acte d’attribuer chaque énoncé au bon locuteur (rarement évalué dans les benchmarks existants !). Ainsi; on peut utiliser un fournisseur en tant que modèle principal et les autres servent de fallback si le premier échoue.

Pour chaque client, nous définissions un profil spécifique qui détermine les fournisseurs STT à utiliser, les modèles LLM, les paramètres de langue et le comportement de résumé. Cette abstraction est ce qui nous a permis de servir plus de 30 clients avec des exigences de conformité et des contraintes d’infrastructure radicalement différentes à partir d’une seule base de code. Par exemple, les clients avec résidence suisse étaient routés vers les modèles disponibles dans Azure Switzerland, tandis que les clients priorisant la performance pouvaient utiliser Speechmatics pour la STT (traitement UE) et les LLM les plus récents, pas encore disponibles pour l’inférence suisse sur Azure.

En interne, nous avons discuté à plusieurs reprises de l’idée de développer notre propre pipeline STT, en utilisant Whisper en open-weight pour la transcription et un traitement de diarisation basé sur PyAnnote, déployé sur des GPU dédiés situés géographiquement en Suisse. Bien que cela nous aurait permis de supprimer les fournisseurs externes (tels que Speechmatics et Gladia) et d’améliorer la souveraineté de la solution, ça représentait aussi beaucoup plus de travail et ajoutait le coût de maintenance de notre propre stack STT, y compris le provisionnement de GPU. Par conséquent, la décision a été prise de reporter ce développement jusqu’à ce qu’un client demande ce niveau de gouvernance et soit prêt à en couvrir les coûts.

2. Attribution des locuteurs et diarisation

Pour ce projet, l’autre paramètre important du traitement STT était la diarisation. La précision avec laquelle un énoncé peut être attribué au bon locuteur compte autant que l’identification des mots corrects, en particulier dans les réunions contenant des éléments juridiquement importants. Cependant, pour des raisons de conformité, des profils vocaux spécifiques n’ont pas été créés, donc NovaNote pouvait identifier un locuteur par le timbre de sa voix mais ne pouvait pas suggérer de nom réel.

Dans NovaNote, nous avons créé un workflow d’attribution des locuteurs où les locuteurs détectés automatiquement peuvent être confirmés, fusionnés ou corrigés manuellement avant le lancement du résumé. Une tâche suggest_speakers utilise le LLM avec le contexte de la réunion pour proposer des identités de locuteurs basées sur les schémas de nomination dans le transcript, réduisant ainsi l’effort de correction manuelle, en particulier pour les réunions récurrentes avec des participants connus.

Par exemple, dans cette séquence (simplifiée) :

« Speaker_A : Je suis d’accord avec cette décision. Et vous, Jean ?

Speaker_B : Je le suis également, Anna. »

NovaNote suggérerait que Speaker_A est Anna et Speaker_B est Jean.

De plus, nous extrayions de petits extraits vocaux (ne contenant aucune information sensible) pour chaque locuteur identifié, permettant à l’utilisateur de jouer l’audio et de reconnaître le participant à sa voix.

Malgré tout cela, l’un des problèmes les plus difficiles que nous avons rencontrés était que la qualité de la diarisation audio varie considérablement selon les fournisseurs et les conditions d’enregistrement. Pour atténuer davantage ce problème, nous avons commencé à travailler sur une fonctionnalité de reconnaissance vocale où :

• Les utilisateurs peuvent s’enregistrer eux-mêmes ou enregistrer d’autres personnes et assigner des noms à chaque identité enregistrée pour améliorer la reconnaissance future par le modèle et suggérer automatiquement le bon nom, même s’il n’est pas déductible du transcript
• Les extraits audio et les saisies utilisateur pour l’attribution des locuteurs sont utilisés pour générer et améliorer les identités vocales des utilisateurs au fil du temps

Tout cela était conforme au fait de ne stocker aucune information sensible chez le fournisseur STT, où le seul workflow accepté était un transit rapide de l’enregistrement pour générer une transcription, puis supprimée.

3. Résumé section par section

Le contenu des réunions n’est pas résumé d’un seul bloc. Le système utilise des templates de réunion : des schémas structurés de sections que l’utilisateur peut personnaliser (par exemple, « Décisions prises », « Points de discussion », « Tâches à venir ») et remplit chaque section indépendamment à l’aide du LLM. Cela produit des comptes rendus cohérents et bien organisés plutôt qu’un mur de texte. De plus, nous contournons la principale limitation des LLM (l’attention) en obligeant à générer une seule section sur un sujet donné à la fois. Avec les modèles de raisonnement SOTA les plus récents, cela peut sembler anodin, mais en 2024 (quand NovaNote a été utilisé pour la première fois), demander à un LLM de générer 5 à 10 pages de texte sur un large éventail de sujets à partir d’un enregistrement de 4 heures était une tâche impossible ! Le mécanisme d’attention du modèle aurait été dispersé, chaque section aurait ressemblé à un résumé paresseux et faire suivre au LLM des instructions spécifiques (sur le ton, le style et le format) n’aurait mené nulle part.

De plus, nous ne sommes pas limités par le nombre maximal de tokens qu’un modèle peut générer et pouvons créer un contenu virtuellement infini. Et enfin, cela a permis aux utilisateurs de définir des instructions spécifiques pour chaque section de leurs templates récurrents : par exemple : « Pour la section ‘Tâches à venir’, utilisez toujours un format à puces incluant une brève description de la tâche, la personne responsable et si possible une échéance. »

Sans oublier que ce comportement nous a permis d’utiliser des modèles plus légers, plus rapides (et moins chers !) comme GPT-4o avec des baisses de précision acceptables.

Le workflow final ressemblait à ceci :

Autres fonctionnalités notables

Assistant d’écriture IA et NoteBot

Au-delà de la transcription, les utilisateurs peuvent invoquer une assistance à l’écriture IA directement dans un éditeur markdown enrichi (MDXEditor) pour reformuler, développer ou ajuster le ton de n’importe quelle section. Cela diffère du simple fait de demander à ChatGPT ou Copilot de « réécrire cette section », car nous utilisons le contexte pertinent de la transcription pour ajouter ou modifier des parties du compte rendu. La puissance des LLM, sans les hallucinations.

NoteBot est un assistant IA contextuel qui répond aux questions ancrées dans le contenu de la réunion, permettant aux utilisateurs d’interroger des décisions ou interventions spécifiques sans avoir à relire l’intégralité du transcript. À terme, NoteBot deviendrait plus général, vivant sur la page d’accueil et permettant de répondre à des questions sur n’importe quelle réunion, voire de rassembler des informations de plusieurs réunions pour répondre à une question spécifique (par exemple, « Retracez l’évolution du projet X de sa conception en mars à son déploiement en décembre »).

Ces deux fonctionnalités empruntent la même abstraction LLM et respectent la configuration de modèle du client.

Stockage agnostique du cloud

Les fichiers audio et les actifs générés sont stockés via CloudPathLib, qui fournit une interface uniforme sur Azure Blob Storage, AWS S3 et le système de fichiers local. Le backend de stockage est sélectionné au moment du déploiement via la configuration d’environnement, ne nécessitant aucune modification de code entre les déploiements cloud et on-premises.

Modèle de données multi-tenant et contrôle d’accès

Le modèle de données est organisé autour des organisations, des équipes et des réunions. Le contrôle d’accès basé sur les rôles est appliqué au niveau de l’API, avec un partage des réunions au niveau de l’équipe et une administration au niveau de l’organisation. L’authentification prend en charge Azure Entra ID pour les clients entreprises intégrés à l’écosystème Microsoft 365 ou d’autres fournisseurs via Keycloak.

Infrastructure et packaging de déploiement

L’infrastructure est gérée avec Terraform ciblant Azure (Container Apps, PostgreSQL Flexible Server, Azure Blob, enregistrement d’application Entra ID, politiques d’auto-scaling). Docker Compose gère les déploiements locaux et on-premises. La même application a été déployée sur InfoManiak OpenStack pour les clients de cloud souverain suisse sans modification de la couche applicative: seuls la cible Terraform et le backend de stockage ont changé.

Et encore plus…

Au fur et à mesure que NovaNote évoluait, de plus en plus de fonctionnalités ont été intégrées pour répondre aux demandes et idées de chaque client. Voici quelques autres choses que nous avons faites :

1. Intégration webhook Microsoft Teams Les réunions enregistrées dans Teams sont automatiquement ingérées, transcrites et traitées, avec une logique de réessai en cas d’erreur. C’était énorme pour les clients de l’écosystème Microsoft.
2. Export DOCX Critique pour les workflows entreprises, les utilisateurs ont besoin du résultat dans Word, pas seulement dans le navigateur.
3. Préconfigurations de réunion Les utilisateurs peuvent enregistrer des configurations de réunion réutilisables : participants, langue, template, vocabulaires, longueur des sections, etc. Une fonctionnalité UX principalement pour les réunions récurrentes (par exemple, un conseil d’administration hebdomadaire a toujours la même configuration).
4. Partage fin des réunions Les réunions peuvent être partagées avec des utilisateurs spécifiques à des niveaux d’accès définis pour collaborer sur les comptes rendus.
5. Extraction d’ordre du jour PDF Téléversez un PDF et le système en extrait automatiquement les points à l’ordre du jour. Utile pour les réunions formelles qui ont déjà un ordre du jour imprimé.
6. Tableau de bord des statistiques d’utilisation Suivi de l’utilisation des modèles, consommation de tokens et prix estimé par minute. Fonctionnalité de facturation/reporting pour les entreprises.

Stack technique

Résultat

• 8h et plus → moins de 20 minutes pour produire un document de compte rendu complet et structuré, rapporté de manière cohérente dans toutes les organisations clientes
• 30+ clients entreprises en production, répartis sur Azure, InfoManiak (cloud souverain suisse) et déploiements on-premises OpenStack
• Conformité totale de résidence des données atteinte pour chaque client, y compris les configurations Suisse uniquement et UE uniquement, sans modification de la couche applicative
• Verrouillage fournisseur minimal à chaque couche : STT, LLM, stockage et infrastructure cloud sont tous remplaçables via la configuration
• 5+ endpoints de modèles LLM configurables par déploiement, avec routage par tâche et fallback automatique
• 4 intégrations de fournisseurs STT avec fallback à l’exécution, aucune panne d’un seul fournisseur ne peut interrompre le pipeline de transcription
• Moyenne de 1 CHF par compte rendu généré, bien que cela puisse varier considérablement selon la durée de la réunion et le texte généré

Ce que je ferais différemment

NovaNote a commencé comme un projet pour un seul client, puis a évolué pour devenir l’une des solutions phares de Novatix. Chaque nouveau client apportait de nouvelles demandes et fonctionnalités à développer. Combiner le développement de fonctionnalités spécifiques, les mises à jour générales de NovaNote et toutes les diverses modalités de déploiement et de conformité n’était pas toujours une tâche simple.

Si je devais recommencer, j’aurais passé plus de temps à étudier le marché et à réaliser que la demande pour une plateforme suisse de comptes rendus de réunions était aussi importante. Cela nous aurait permis d’anticiper la croissance de NovaNote et de concevoir ses fondations autour d’un produit de type « SaaS » plutôt que d’une application web spécifique à un client. Nous aurions gagné beaucoup de temps si nous avions développé des éléments comme les feature flags, les releases et mises à jour automatisées, les profils de pipeline de traitement et les déploiements multi-tenant / multi-infrastructure dès le début. Mais la mère d’un homme sage l’a dit un jour :

« Life is like a box of chocolates, you never know what you’re going to get! »