Vos systèmes IA en production. Mesurés, intégrés, et à vous.

Problème

Keytt avait besoin d'un produit complet : tableau de bord, planificateur de contenu propulsé par LLM, mise en relation avec des experts, analytics. Assez vite pour montrer de la traction dans un pitch investisseurs.

Ce qu'on a construit

La plateforme complète, de bout en bout. React + Node + Postgres sur AWS, assistant de planification de contenu propulsé par OpenAI, moteur de scoring, algorithme de mise en relation, onboarding automatisé.

Résultat

MVP en ligne en moins de 6 semaines. Devenu l'actif central du deck de levée de Keytt. L'architecture est toujours en production aujourd'hui.

Problème

Les DRH assemblaient à la main leurs analyses d'effectifs, de turnover et d'égalité salariale, puis en rédigeaient le commentaire à la main par-dessus. La solution évidente — laisser un modèle interroger la base RH — est précisément celle qu'on ne peut pas livrer sur des données de paie couvertes par des obligations de dépôt légal.

Ce qu'on a construit

Un service IA Python distinct derrière l'API, portant deux machines à états LangGraph. Une question en français renvoie des paramètres de graphique stricts, jamais du SQL : le modèle propose, la couche de données déjà permissionnée exécute, et une passe de correction rattrape les plages de dates que les modèles inventent systématiquement. Le commentaire rédigé arrive en flux sur chaque graphique et chaque section de rapport, régulé par un cache partagé et un plafond de concurrence pour qu'un rapport réglementaire de plusieurs dizaines de sections n'ouvre pas autant de flux. Les prompts se versionnent séparément du code, chaque exécution est tracée, et le pouce vers le bas sous un insight se rattache à cette exécution précise.

Résultat

Des tableaux de bord construits en posant la question. Des rapports réglementaires qui arrivent avec leur commentaire déjà rédigé, modifiable et validé par un humain. Des synthèses planifiées qui se lisent toutes seules dans la boîte mail — et qui partent quand même si le modèle échoue. Staffdesk fait état de plus de 60 % de temps gagné sur le reporting RH. Un premier agent text-to-SQL a été construit, mesuré sur un jeu de données annoté, puis retiré volontairement : c'est l'architecture la plus sûre qui est partie en production chez les grands comptes.

Problème

Un système IA qui cite une source paraît fiable même quand il se trompe. Pire : le droit change, et les versions abrogées restent dans les bases. La réponse est alors bien rédigée, bien sourcée, et fausse. Le corpus est du droit du travail parce qu'il est public et vérifiable par n'importe qui ; le problème est celui de toute entreprise dont les documents se contredisent et vieillissent.

Ce qu'on a construit

Vous posez une question, vous voyez le système travailler en quatre étapes : il cherche dans 3 030 articles, il écarte ceux qui ne sont plus en vigueur, il garde les cinq plus pertinents, il rédige à partir de ceux-là et de rien d'autre. Chaque réponse affiche l'article qui la fonde et sa date. En dessous, 142 questions annotées à la main et six configurations comparées mesurent ce que ça vaut vraiment.

Résultat

L'article qui tranche est retrouvé dans 90,8 % des cas. Aucun texte abrogé servi, contre 63,3 % sans le filtre de date. La justesse des réponses est publiée en fourchette et étiquetée non validée, faute de juriste pour trancher. Code ouvert, méthode et échecs documentés.