Un produit caché dans un autre

Momentum est un coach IA destiné aux managers. Il permet aussi bien des échanges écrits que des conversations vocales avec des agents IA jouant le rôle d'un collaborateur direct du manager.

Lorsque j'arrive sur le projet, Momentum existe sous la forme d'un prototype interne développé au sein de la codebase historique de Fifty. Le fondateur pense que le nouveau produit pourra réutiliser une grande quantité de code existant.

En pratique, les deux produits ont très peu de code réellement commun. Cette situation commence à peser sur la vélocité de l'équipe : faire évoluer Momentum implique de travailler dans une application qui n'a pas été conçue pour lui.

Découper sans tout casser

La première étape consiste donc à sortir Momentum de cette codebase sans altérer le produit historique.

Je pars d'une copie du repository, qui reste temporairement liée à l'original. J'identifie ensuite les points d'entrée utilisés par le nouveau produit et remonte les dépendances nécessaires à leur fonctionnement.

Le code qui n'est plus atteignable depuis ces points d'entrée peut alors être progressivement supprimé. Cette technique de slicing, issue de travaux de recherche des années 1990 mais rarement utilisée dans l'industrie, permet de réduire le projet à ce qui lui appartient réellement.

Le résultat est particulièrement révélateur : environ 90 % du code initial n'appartient qu'à l'ancien produit.

L'opération demande de la méthode et de la prudence. Une dépendance inattendue peut rendre une suppression dangereuse et nécessiter un retour arrière. Après environ un mois, Momentum dispose finalement de son propre dépôt, débarrassé du code qui n'était pas nécessaire à son fonctionnement.

Industrialiser un prototype

Le produit reste alors un prototype qui se cherche encore. Les fonctionnalités évoluent rapidement au gré des retours des premiers utilisateurs. L'objectif n'est donc pas de construire immédiatement une architecture figée et surdimensionnée, mais de donner à l'équipe les moyens de livrer et d'expérimenter.

Je construis les environnements de production et de préproduction sur AWS et la chaîne CI/CD.

Le principe est celui du You build it, you run it : Le produit peut alors être déployé indépendamment de l'application historique.

Dans cette phase, l'effort porte en priorité sur les fonctionnalités et les retours utilisateurs. Le produit évolue encore rapidement : l'enjeu est de conserver une architecture suffisamment souple pour intégrer ces apprentissages sans multiplier prématurément les contraintes. Les investissements de qualité sont renforcés progressivement à mesure que le produit se stabilise.

Faire fonctionner la voix en temps réel

La partie la plus exigeante techniquement concerne la conversation vocale. Momentum combine plusieurs technologies qui doivent fonctionner ensemble en temps réel : Speech to Text, Text to Speech, Voice Activity Detection, communication temps réel et modèles de langage.

J'ai intégré l'ensemble de cette chaîne au produit. Pour la détection d'activité vocale, j'ai notamment développé un algorithme adapté au besoin à partir du réseau de neurones Silero.

Le système ne se limite pas non plus à un appel isolé à un LLM. Plusieurs agents sont orchestrés : certains surveillent d'autres agents, certains gèrent les outils à leur disposition et d'autres interviennent pour reformuler ou traiter les réponses.

La difficulté vient surtout de leur faire fonctionner ensemble. Latence, interruptions, détection de la parole, génération et restitution audio doivent s'enchaîner suffisamment rapidement pour que la conversation reste naturelle.

Deux mois ont été consacrés à fiabiliser cette chaîne et à en améliorer les performances. C'est le principal défi technique de la mission.

La qualité au bon moment

Une fois les premiers utilisateurs embarqués, le contexte évolue. Le produit compte alors environ soixante bêta-testeurs et commence à se rapprocher d'une véritable bêta fonctionnelle.

Il devient alors pertinent d'investir davantage dans la qualité. J'interviens avec le reste de l'équipe sur l'ajout de tests fonctionnels, le remaniement de l'architecture et la fiabilisation de la chaîne CI/CD.

L'objectif n'est pas de revenir sur les choix faits pendant la phase de découverte du produit. Il s'agit de transformer progressivement un prototype qui devait pouvoir changer rapidement en un logiciel capable de continuer à évoluer sans perdre cette vélocité.

Cette approche permet de différer volontairement certains investissements tant qu'ils ne créent pas de valeur, puis de les introduire lorsque le produit commence à se stabiliser.

Du prototype à la bêta

En cinq mois, Momentum passe d'un prototype interne enfoui dans la codebase historique de Fifty à un produit indépendant, disposant de ses propres environnements, de sa chaîne de déploiement et d'une soixantaine de bêta-testeurs.

À mon départ, le produit est une bêta fonctionnelle. La remontée de la qualité logicielle est en cours : les tests, l'architecture et les derniers points techniques sont progressivement renforcés.

Préserver la vélocité

Cette mission illustre une autre facette de mon travail. Toutes les situations ne nécessitent pas immédiatement le même niveau de formalisme.

Sur un produit qui cherche encore son marché, la capacité à expérimenter et pivoter peut être plus importante que l'accumulation de tests et de documentation. Mais lorsque le produit commence à trouver ses utilisateurs, les exigences changent : il faut alors transformer cette vitesse d'apprentissage en capacité durable à évoluer.

Mon objectif n'est pas de ralentir une équipe pour rendre son code parfait. C'est de lui permettre de rester agile sans que la dette technique finisse par lui retirer cette agilité.