MWS supprime le bruit des appels directement dans le réseau de l’opérateur : 20 ms pour le traitement

« On va brancher un réseau de neurones » : la formule paraît simple, jusqu’à ce qu’on se heurte aux millisecondes, aux tokens et à un objectif mal défini. Lors du onzième meetup MWS, trois présentations ont décortiqué ces obstacles dans les appels, la documentation d’architecture et la planification stratégique. Voici ce que les praticiens peuvent en retenir.

Le bruit est supprimé dans le réseau, pas sur le téléphone

Maxime Maslennikov, Cluster lead Architect chez MWS, a présenté un système de réduction du bruit côté opérateur. Il fonctionne sans application et sans intervention du smartphone : la voix est nettoyée avant de parvenir à l’interlocuteur. L’idée est née après un incident dans le métro, où le dirigeant de l’entreprise n’avait pas pu tenir une conversation normale à cause du bruit.

La mise en œuvre s’est révélée la plus difficile. En 2G et en 3G, la voix emprunte un canal dédié ; l’équipe y a envisagé d’acheminer l’appel au moyen d’un préfixe spécial. En LTE, les appels passent par IMS, donc sous forme de paquets IP. L’équipe y a intégré son propre service média, par lequel transite le flux vocal. Il n’est pas nécessaire de changer de numéro.

La principale contrainte est le temps. Il faut recevoir chaque paquet, le convertir dans un format adapté au réseau de neurones, le nettoyer et le retransmettre en environ 20 ms. Si ce délai est dépassé, les interlocuteurs entendent des claquements et des coupures. Le modèle traite une conversation continue, et non des enregistrements séparés. Il a donc fallu l’adapter pour qu’il conserve son état entre les fragments.

Les modèles ouverts d’amélioration de la parole disponibles ne convenaient pas sans adaptation. L’équipe les a affinés sur des enregistrements de bruits réels, notamment celui d’un compresseur en fonctionnement. Pour éviter de solliciter fortement les GPU à chaque conversation, elle a ajouté un petit modèle de surveillance : il détermine quand un traitement lourd est nécessaire et quand un algorithme léger suffit. La géographie compte aussi : plus le nœud de traitement est éloigné de l’abonné, plus il est difficile de respecter la contrainte de latence.

Le système a aussi ses défauts : le traitement modifie légèrement la voix, même si elle reste intelligible. La solution est déjà en production, mais MWS ne prévoit pas de publier les poids des modèles. Prochain chantier : reconstituer la voix perdue lors de la transmission sur le réseau.

Des agents qui réparent la documentation

Evgueni Artemiev, Stream lead Architect chez MWS, a présenté un outil qui s’attaque à un problème classique : le code a évolué, mais les documents d’architecture sont restés figés. Les nouveaux microservices et les modifications des API ne sont pas intégrés à la description du système, qui ne correspond plus à la réalité.

L’outil collecte des données dans les dépôts, DevOps, Jira et Confluence. Un premier agent analyse les changements et sélectionne les documents pertinents ; un second les synthétise et prépare des propositions de mise à jour. Un orchestrateur coordonne le travail, tandis qu’une couche distincte retire les informations confidentielles avant l’envoi au modèle. L’outil produit des fichiers YAML et Markdown qui permettent de repérer les technologies obsolètes, d’examiner les liens entre les systèmes et d’évaluer les risques. L’architecte décide des modifications à apporter.

Le point le plus utile de la présentation est la comparaison entre deux modes de fonctionnement. En mode déterministe, les développeurs définissent à l’avance les étapes et les outils. En mode non déterministe, l’agent décide lui-même de la marche à suivre. Lors d’une expérience avec Claude, la seconde option a donné de moins bons résultats : le modèle consommait davantage de tokens, effectuait des actions superflues et respectait moins bien la structure. L’équipe a donc choisi LangGraph, qui permet de définir les étapes et les transitions autorisées, tout en faisant travailler plusieurs agents en parallèle. En contrepartie, le débogage devient plus complexe : il faut suivre l’état de chaque agent et sauvegarder les résultats intermédiaires.

Autre piège : le contrôle des données avant leur envoi au modèle. Il peut s’effectuer à l’aide d’expressions régulières ou d’un modèle de classification. Mais, dans l’un des projets, le classificateur sur CPU prenait trois à quatre secondes, pour une limite de 500 ms.

« Carte des hypothèses » : l’humain fixe toujours l’objectif

Alexandre Byndiou a présenté une méthodologie qui relie les objectifs de l’entreprise, ses ressources et les conditions externes à ses paris stratégiques. Elle repose sur une analyse SWOT croisée. Son idée centrale : accélérer certaines opérations ne garantit pas la croissance de l’entreprise. Rédiger un courrier en cinq minutes au lieu de deux heures fait gagner du temps, mais n’augmente pas nécessairement le chiffre d’affaires.

Dans un cas pratique, l’IA a construit une carte à partir d’un petit PDF et a obtenu un résultat proche de la réalité. Mais tout dépend de la formulation de l’objectif : une erreur à ce stade conduit à choisir de mauvais indicateurs, ce qui apparaît immédiatement lors de la comparaison avec la référence. Dans une seconde démonstration, le modèle, doté de compétences issues de GitHub, a posé des questions de clarification et produit une carte accompagnée d’un prototype d’interface.

Il s’est trompé dans la définition du sujet de l’analyse, qu’il a fallu corriger manuellement. Lorsqu’il est apparu que l’une des tendances n’existait pas, les données ont été remplacées et une nouvelle version a été obtenue en une dizaine de minutes. La valeur du prototype tient ici à la rapidité du retour, et non à la qualité de sa réalisation.

Les limites sont clairement exposées : une partie des liens se configure manuellement, et l’utilisateur doit connaître la méthodologie pour guider le modèle et évaluer ses réponses.

Ce qu’il faut retenir pour la pratique

Pour terminer, les participants ont imaginé des services reposant sur les technologies MWS : un assistant pour les managers, un concierge vocal, un traducteur et un assistant chargé de joindre les services publics par téléphone. Pour des usages comme la consignation des accords conclus, la question de la valeur juridique du résultat reste ouverte.

Trois règles se dégagent. Pour le temps réel, commencez par calculer le budget de latence et le coût des GPU, puis utilisez une cascade associant un modèle léger et un modèle lourd. Pour les agents, partez d’un graphe strict et n’assouplissez ses contraintes que là où cela se justifie, en mesurant au préalable le coût des contrôles de protection. Pour les tâches stratégiques, consacrez du temps à la formulation de l’objectif : la qualité de tout le reste en dépend.

Réserve : cet article restitue les présentations des développeurs eux-mêmes. Aucune mesure indépendante de la qualité de la réduction du bruit ou de la précision des agents n’est fournie.