Mettre en production le moteur IA MIA

MIA était une plateforme IA no-code construite autour d’un registre de modèles et d’une surface de workflow permettant à des non-ingénieurs de composer des pipelines. Le produit avait un moteur de niveau recherche et un frontend qui ne suivait plus. Six mois chez Digitalent ont servi à combler cet écart.

Le frontend devait ressembler à un produit

L’interface MIA tournait en rendu côté client, ce qui rendait le premier paint lent et l’expérience pas finie — lourde sur une station de travail, pénible sur tout le reste. On l’a reconstruit sur Nuxt en rendu côté serveur.

Le gain était direct : temps de chargement divisés par deux sur les routes qui comptaient. Le gain plus profond, c’est ce que le SSR nous a forcés à penser — frontières d’hydratation, où s’arrêtait la sortie du serveur et où commençait l’interactivité du client, quel état faisait foi sur le câble et quel état était local. Chaque composant devait déclarer ses frontières. La base de code est devenue plus honnête comme effet de bord.

La rétention utilisateur s’est améliorée dans les mois qui ont suivi. Difficile de l’attribuer proprement au seul travail SSR, mais les indicateurs en amont — taux de rebond au premier paint, time-to-first-interactive — ont bougé dans le bon sens.

Conteneurisation du ML pour qu’il passe à l’échelle

Le côté ML tournait en service Flask que le frontend appelait. Ça marchait à faible trafic et ça cassait au point d’inflexion où le trafic d’inférence dépassait une seule instance.

On a conteneurisé la charge — images Docker par variante de modèle, Kubernetes les orchestrant sur AWS, autoscaling lié à la profondeur de la file d’inférence. Le frontend est resté presque identique ; le contrat avec la couche ML n’a pas changé. Ce qui a changé, c’est qu’on pouvait scaler horizontalement sans intervention manuelle, et la plateforme a arrêté de plier sur les pics de trafic.

Le travail d’autoscaling a tenu face à la croissance. Le trafic n’a pas cessé de monter pendant que j’étais là ; le système a suivi.

Un pipeline qui livrait vraiment

La cadence de release était l’autre levier. L’équipe livrait au mois, parfois moins, avec une vérification manuelle entre le merge et le déploiement. J’ai instrumenté GitHub Actions CI/CD par-dessus la surface de tests existante — chaque PR lançait la suite complète, chaque merge déclenchait un candidat de déploiement, chaque candidat avait un chemin de promotion en un clic.

La cadence est passée de mois à semaines. Les ingénieurs ont arrêté de regrouper leurs changements pour profiter d’un seul déploiement. Le coût d’un petit fix est passé de « on attend la prochaine release » à « on merge et on regarde ».

Partenariat avec les ingénieurs IA

Le travail le plus intéressant était à la couture entre l’application et le modèle. Les ingénieurs IA faisaient un travail sérieux sur les modèles ML et adjacents-LLM — signaux prédictifs, têtes de classification, tâches de langage. Mon rôle à cette couture était de la traduction : leur sortie de recherche en quelque chose que le frontend pouvait appeler, surveiller, et dont il pouvait récupérer quand le modèle se comportait mal.

On a posé le versioning de modèles, le logging des prédictions, et un comportement de mode dégradé pour quand un appel d’inférence dépassait son délai. Rien de ça n’est de la recherche neuve. Mais c’est le travail qui doit se faire pour qu’un produit IA soit un produit.

Six mois n’ont pas suffi à tout livrer. Mais ça a suffi à poser la fondation sur laquelle le côté IA pouvait continuer à construire. C’est la version de l’ingénierie IA que je trouve la plus utile — pas la démo, le déploiement.