Réalisations · preuve d'ingénierie

Ce que nous avons construit.

Le travail client est confidentiel par défaut ; voici donc des études de cas d'ingénierie tirées de systèmes que nous construisons et opérons nous-mêmes — écrites depuis le code, pas depuis un argumentaire.

Chaque mécanisme décrit ici tourne en production et peut être inspecté dans le cadre d'un mandat.

Étude de cas 01

Une plateforme d'opérations IA, exploitée en production

Une plateforme de productivité multi-locataire où l'IA est la couche opérationnelle, pas une fonctionnalité : assistants, voix, automatisations, retrieval et tableaux de bord pour des équipes travaillant en neuf langues. Nous la construisons et l'opérons — chaque décision d'architecture présentée sur ce site a donc été payée au moins une fois.

Ce qu'elle contient

Une seule couture agent

Chaque complétion passe par un chemin unique et instrumenté — vérification de budget, sélection de modèle avec chaînes de bascule sur cinq fournisseurs, l'appel, journalisation d'usage par appel avec le coût en dollars. Pydantic AI est le framework ; changer de modèle est une règle de routage.

Des assistants ancrés

Un clavardage en continu où les citations sont vérifiées contre les preuves réellement récupérées — les citations invérifiables sont signalées, pas affichées. Les appels d'outils sensibles deviennent des demandes d'approbation, et les écritures risquées attendent un humain.

Voix en duplex intégral

Reconnaissance vocale en continu, le même runtime agent gouverné que le clavardage, et une synthèse vocale renvoyée phrase par phrase — avec interruption au vol qui coupe la lecture dès que l'appelant parle.

Un retrieval qui connaît ses limites

Recherche hybride — similarité pgvector fusionnée au plein texte Postgres par reciprocal rank fusion — derrière une porte déterministe qui décide si le tour a besoin de retrieval, et une vérification de suffisance qui relance une fois quand l'ancrage est mince.

Une mémoire avec consentement

L'agent propose des souvenirs ; un humain les approuve avant qu'ils n'entrent dans un prompt. La suppression laisse une pierre tombale qui empêche le fait d'être re-dérivé.

MCP dans les deux sens

L'API de la plateforme est servie comme serveur MCP avec OAuth 2.1, portées et limites de débit — et les utilisateurs connectent des serveurs MCP externes depuis un catalogue organisé, avec une sortie réseau protégée contre le SSRF.

Les évaluations comme porte

Un harnais pydantic-evals avec quinze suites versionnées et des portes de régression contre référence. Les pouces levés et baissés de l'usage réel alimentent chaque nuit des cas d'évaluation candidats.

Une gouvernance qui s'exécute

Un point de décision de politique unique qui résout refuser avant demander avant permettre, une règle selon laquelle le contenu non fiable n'est jamais une instruction, des portes d'approbation sur les écritures et un interrupteur d'urgence sur les appels sortants.

La partie difficile

L'économie du contexte. Un agent avec une grande surface d'outils dépensait environ 53 000 jetons par appel juste pour décrire ses outils ; le chargement différé des outils — noms et descriptions d'une ligne d'abord, schémas complets à la demande — a ramené cela à environ 8 000. Ajoutez le cache de prompts sur le préfixe stable et les API par lots pour les pipelines d'arrière-plan, et la dépense de modèles est devenue un poste ajustable et attribuable plutôt qu'un mystère.

Ce que ça prouve

Les composants du studio présentés sur ce site ne sont pas une proposition — ils sont extraits de ce système. Quand un mandat a besoin d'un assistant, d'une ligne vocale, d'un harnais d'évaluation ou d'une intégration MCP, le patron arrive déjà débogué.

Étude de cas 02

Rendre un produit accessible aux agents

Un site produit public reconstruit pour que les agents IA soient des visiteurs de première classe. Le pari : les acheteurs demandent de plus en plus à leur assistant avant de demander à un moteur de recherche, et le site qu'un agent peut lire proprement gagne cette conversation.

Ce qu'il contient

Un serveur MCP public

Le contenu du site marketing servi comme outils appelables — lister les pages, chercher le site, récupérer une page — hébergé en périphérie, pour que tout client MCP interroge le produit directement.

Des Agent Skills publiées

Deux douzaines de documents de compétences sous /.well-known/, générés depuis le contenu du site, pour que les agents qui supportent le format chargent exactement la procédure dont ils ont besoin.

llms.txt et découverte

Un index du site organisé et lisible par les LLM, plus des documents de découverte OAuth — une seule requête dit à un agent ce qu'est le produit et où vivent les réponses canoniques.

WebMCP dans la page

Des outils enregistrés dans la page via navigator.modelContext — consultation des prix, recherche de pages, accès anticipé — pour qu'un agent résident du navigateur agisse par une surface sanctionnée au lieu de gratter le DOM.

La partie difficile

Garder quatre surfaces de découverte véridiques en même temps. Les compétences, les outils MCP et llms.txt sont générés depuis la même source de contenu dans le pipeline de build : un changement de texte ne peut pas laisser un agent lire une version périmée du produit.

Ce que ça prouve

Ce site pratique ce qu'il recommande : groupemedia.ca publie lui-même son llms.txt et enregistre des outils WebMCP. Rendre votre produit lisible par les agents est une tâche de construction qui se mesure en jours — et nous l'avons fait plus d'une fois.

Vous voulez la même discipline appliquée à votre opération ?

Voir comment se déroulent les mandats