SMCI : le framework pour industrialiser vos agents IA

La plupart des projets d'agents IA qui échouent partagent la même cause racine : on a confondu l'expérience de l'agent avec l'ingénierie de l'agent. Quand on prompte ChatGPT à 23h pour résumer un PDF, on a une expérience. Quand on déploie un agent en production qui doit pré-instruire 800 dossiers par mois, sans dériver, sans halluciner, sans casser quand on change un fournisseur, on fait de l'ingénierie. Les deux activités n'ont pas la même méthode.

Chez GEOVTC, nous utilisons un framework propriétaire — SMCI — pour structurer cette ingénierie. Quatre dimensions à modéliser explicitement avant tout codage : Skills, Memory, Context, Identity. Ce qui suit en explique l'usage opérationnel, à partir d'exemples réels.

Pourquoi un framework, et pas juste de bons prompts

L'industrie de l'IA est inondée de tutoriels "prompt engineering". Ils sont utiles pour démarrer. Ils ne suffisent pas pour livrer. Un prompt magnifique sur un agent dont la mémoire fuite, dont les outils sont mal cadrés, ou dont l'identité dérive sous pression utilisateur — c'est un système qui tombera, dès que la situation s'éloignera des cas couverts pendant le test.

L'ingénierie des agents IA répond à la même contrainte que toute ingénierie : produire un système prévisible, testable, gouverné, dont les modes de défaillance sont connus à l'avance. Le prompt, dans cette discipline, est un livrable parmi d'autres — pas l'objet principal.

SMCI permet de poser le problème dans le bon ordre : avant de demander à un agent comment se comporter (prompt), on définit ce qu'il sait faire (Skills), ce qu'il retient (Memory), ce qu'on lui passe (Context), et qui il est (Identity). Une fois ces quatre dimensions cadrées, le prompt devient presque évident.

S — Skills : la frontière des capacités

Les Skills d'un agent, ce sont ses capacités d'action et de récupération d'information : les API qu'il peut appeler, les bases qu'il peut interroger, les outils qu'il peut déclencher, les transformations qu'il peut produire. On les définit en termes d'opérations, pas en termes de prompts.

Exemple : un agent de pré-revue de contrats fournisseurs aura typiquement les Skills suivants : extract_text_from_pdf, find_clauses(types: [confidentiality, liability, jurisdiction]), compare_to_baseline(clause, template_id), lookup_supplier(siren), flag_for_review(reason, severity), notify_user(channel, message).

L'erreur classique consiste à donner trop de Skills à un agent — sous prétexte que "ça peut servir". Chaque Skill ajoutée élargit la surface de décision de l'agent, et donc sa surface de défaillance. La règle GEOVTC : un Skill n'entre que s'il est nécessaire à un cas d'usage cadré et que sa non-utilisation laisserait un manque opérationnel.

Le second réflexe d'ingénierie sur les Skills, c'est la typage strict des entrées et sorties. Un Skill mal typé est un Skill que l'agent appellera mal. On définit chaque Skill comme une fonction avec son schéma JSON, on teste ses cas limites, et on documente son comportement attendu. Cela ressemble à une API interne — parce que c'en est une.

M — Memory : ce que l'agent retient entre deux exécutions

La Memory, c'est ce qui fait qu'un agent n'est pas une fonction sans état. Sans mémoire, il oublie tout entre deux conversations : vos préférences, l'historique des décisions, les exceptions tolérées. Cela peut être acceptable pour un assistant ponctuel ; ce n'est jamais acceptable pour un agent industriel.

On distingue trois couches de Memory dans un déploiement typique :

• Mémoire courte : l'historique d'une session ou d'une exécution. Tient en context window.
• Mémoire longue : l'historique persistant — décisions passées, retours utilisateur, motifs d'exception. Stockée dans une base, indexée pour recherche sémantique.
• Mémoire structurée : les données métier de référence — fournisseurs, produits, plan comptable, organigramme. Lue à la demande, jamais inférée.

L'erreur la plus dangereuse en matière de Memory, c'est la mémoire implicite : laisser l'agent "se souvenir" via le contexte d'une longue conversation, sans persistance explicite. Cela produit des comportements imprévisibles, non auditables, et dépendants du modèle sous-jacent. Toute information qui doit survivre à la session doit être écrite explicitement dans une couche de mémoire que vous contrôlez.

Deuxième point d'attention : la politique d'écriture en mémoire. Qui décide ce qui est écrit, mis à jour, ou archivé ? Si vous laissez l'agent décider seul, vous obtenez de la dérive — il finit par mémoriser ses propres erreurs comme des vérités. La règle GEOVTC : l'écriture en mémoire longue passe par des Skills explicites, avec validation humaine ou règle déterministe sur les transitions critiques.

C — Context : ce qu'on injecte à chaque exécution

Le Context, c'est ce que l'agent reçoit au moment d'agir : les données métier de la situation présente, les contraintes du moment, les paramètres spécifiques à cet appel. C'est la dimension la plus instable d'un agent en production, et la plus sous-estimée en POC.

Un agent qui tourne sur des données synthétiques en démo bénéficie d'un Context idéal : propre, structuré, complet. Le même agent en production reçoit des données partielles, ambiguës, contradictoires, parfois fausses. La résilience de l'agent à un Context dégradé est ce qui sépare un prototype d'un produit.

Trois principes d'ingénierie sur le Context :

Principe 1 — minimisation. Ne passez à l'agent que ce dont il a besoin pour la décision présente. Plus de Context, ce n'est pas plus de qualité — c'est plus de latence, plus de coût, et plus de surface pour les hallucinations. Si l'agent doit pré-instruire une facture, ne lui donnez pas tout l'historique du fournisseur ; donnez-lui les trois dernières factures et leur traitement.

Principe 2 — typage. Un Context bien structuré (JSON, schéma explicite) est traité de manière plus prévisible qu'un Context en prose libre. Quand vous décrivez la situation, faites-le avec une grammaire que l'agent peut parser.

Principe 3 — sources tracées. Chaque élément de Context doit pouvoir être rattaché à sa source (système, document, date). En cas d'audit ou d'erreur, on doit pouvoir remonter à ce qui a été passé à l'agent au moment T.

I — Identity : ce que l'agent est, et ce qu'il refuse

L'Identity, c'est la dimension la plus négligée des frameworks "prompt engineering" — et c'est celle qui décide de la robustesse en production.

Une Identity d'agent comprend cinq éléments :

• Rôle : ce que l'agent fait dans l'organisation. "Pré-instructeur de factures fournisseur" et non "assistant comptable polyvalent".
• Périmètre : ce qu'il fait et ce qu'il ne fait pas. Explicite, court, lisible. "Je ne valide pas les écritures finales. Je ne réponds pas aux fournisseurs. Je ne modifie pas le plan comptable."
• Garde-fous : les comportements interdits. "Je ne dois jamais fournir d'avis juridique. Je ne dois jamais inventer un numéro de SIREN. Si je n'ai pas l'information, je l'écris."
• Ton : la manière dont l'agent communique. Factuel, sobre, concis pour un agent finance. Empathique et pédagogique pour un agent RH.
• Escalade : ce qu'il fait quand il sort de son périmètre. Vers qui, avec quel contexte, avec quelle priorité.

L'Identity est ce qui permet à l'agent de refuser. Un agent sans Identity claire répond à tout, accepte toutes les demandes, et finit par produire des sorties incohérentes ou hors-sujet. Un agent dont l'Identity est cadrée sait dire "ce n'est pas mon rôle, je passe la main".

Comment SMCI s'instancie sur un cas réel

Prenons le cas d'un agent que nous avons déployé en 2026 pour une PME industrielle de 180 salariés : la pré-revue des écritures de clôture mensuelle.

• Skills : list_unposted_entries(period), check_account_consistency(entry), compare_to_history(entry, lookback_months), detect_anomaly(entry, rules), propose_correction(entry), escalate_to_controller(entry, reason).
• Memory : mémoire structurée du plan comptable, mémoire longue des écritures atypiques validées dans les 12 derniers mois, mémoire courte de la session de revue.
• Context : pour chaque écriture en revue, l'agent reçoit l'entrée elle-même, les écritures du même compte sur 3 mois, les règles métier du contrôleur de gestion, les seuils d'alerte.
• Identity : "Pré-instructeur d'écritures. Je ne valide jamais. Je ne modifie jamais une écriture. Je classe en trois bacs : OK, à revoir, anomalie majeure. J'explique mon raisonnement en une phrase. Si je ne sais pas, je classe en 'à revoir' et j'explique l'incertitude."

Cet agent traite 600 à 800 écritures par mois. Le contrôleur de gestion ne revoit plus que les 12 à 20 % classées "à revoir" ou "anomalie". Gain mesuré : 4 jours par mois. Aucune dérive sur 9 mois de production. La clé n'est pas le prompt — qui tient en 40 lignes. La clé est la cohérence des quatre dimensions modélisées en amont.

Ce que SMCI vous évite

Trois échecs typiques que SMCI permet d'éviter en amont :

L'agent qui hallucine sous pression. Cause racine : Identity floue, Memory implicite, Context trop large. Quand l'agent reçoit une demande qui sort de son cadre, il invente plutôt que de refuser. SMCI rend explicite ce qui est dans le cadre et ce qui n'y est pas.

L'agent qui dérive avec le temps. Cause racine : Memory mal gouvernée. L'agent finit par traiter ses propres sorties comme des entrées de référence. SMCI sépare la mémoire d'action (modifiable par l'agent) de la mémoire de référence (modifiable uniquement par les humains ou par des règles déterministes).

L'agent qu'on ne sait plus auditer. Cause racine : Skills trop génériques, Context non tracé. Quand le DSI demande "pourquoi l'agent a-t-il fait X ?", on ne sait pas reconstruire la décision. SMCI impose la traçabilité dès la conception.

Une discipline, pas un produit

SMCI n'est pas un outil que vous installez. C'est une discipline d'ingénierie. Elle se traduit en livrables : une spécification SMCI par agent, validée par le métier et le DSI, avant tout codage. Cette spécification fait 8 à 15 pages, et elle est ce qui rend le projet maintenable : six mois plus tard, on sait pourquoi l'agent a été conçu comme il l'est, et on peut le faire évoluer sans casser l'existant.

C'est cette discipline qui sépare une AI Factory d'une AI Lab. Et c'est ce que nous demandons à chacun de nos clients d'adopter — pas comme une contrainte, mais comme la condition pour que l'investissement en agents IA produise de la valeur au-delà du premier trimestre.