Pourquoi MIC ?¶

MIC est né d'une douleur observée sur six services Python en production : le même socle était réécrit dans chaque service, avec des variations qui finissaient par faire diverger les comportements. L'implémentation Node.js ne copie pas Python ligne par ligne ; elle vérifie que les mêmes garanties peuvent rester explicites et idiomatiques dans un autre runtime.

Les douleurs résolues¶

1. Le même socle, réécrit différemment¶

Symptôme. Chaque service possède son constructeur de routes, son enveloppe de réponse et son mapping d'erreurs. Deux services renvoient une erreur métier en 400 ou 409, un autre la laisse remonter en 500.

Avec MIC. Python utilise HttpRouteSpec; TypeScript utilise route(). Dans les deux cas, les adaptateurs partagent le contrat, les enveloppes et le mapping canonique. Une correction se fait dans la bibliothèque et se prouve sur tous les adaptateurs pris en charge.

2. Le framework qui fuit dans le métier¶

Symptôme. Le domaine importe fastapi.HTTPException, Request d'Express ou un décorateur NestJS. Tester sans démarrer le framework devient difficile, et changer d'adaptateur oblige à réécrire les cas d'usage.

Avec MIC. Les gestionnaires reçoivent des données validées et retournent un résultat MIC canonique. Le métier ne connaît que ses contrats et ses erreurs de domaine. Les tests de parité vérifient ensuite que chaque adaptateur expose le même comportement.

3. L'authentification inter-service qui diverge en production¶

Symptôme. Une clé partagée est codée en dur, la rotation casse un appel, ou un jeton destiné à service-A est accepté par service-B.

Avec MIC. ServiceAuthSigner et ServiceAuthVerifier lient chaque jeton à une audience, acceptent une rotation contrôlée et imposent des portées exactes. Un collecteur compromis reste limité aux opérations explicitement accordées.

4. Des tests flatteurs qui ne prouvent pas les frontières¶

Symptôme. La couverture est élevée, mais le mapping d'une erreur, un header de corrélation ou l'archive réellement publiée n'est jamais exercé.

Avec MIC. L'implémentation Python impose les tests miroir et 100 % des lignes et branches. L'implémentation Node.js exécute ses tests natifs, inspecte les archives npm, puis installe les paquets publiés dans un projet vierge et vérifie le service généré. Les deux privilégient le comportement public.

5. Les services qui communiquent par une base partagée¶

Symptôme. Deux services partagent une table. Une migration du premier peut casser le second sans modification de son code.

Avec MIC. Chaque service possède ses données. La communication passe par HTTP signé, événements versionnés ou read-models explicitement synchronisés. Voir l'anti-pattern de la base partagée.

6. Ajouter un service consomme le temps du métier¶

Symptôme. Le premier endpoint arrive après plusieurs jours de copie, d'authentification, de health checks, de configuration et de tests répétitifs.

Avec MIC. Le cookiecutter Python et @mic-struct/create-mic-service côté Node.js génèrent un service vérifiable avec santé, état de préparation, observabilité, module exemple et tests. Le générateur Node fournit aussi le contrat OpenAPI et la CLI opérateur.

Les douleurs non résolues¶

MIC ne fait pas votre métier. Les règles, invariants et décisions produit restent dans votre service.
MIC ne déploie pas à votre place. Kubernetes, Compose, VPS et supervision restent des choix d'infrastructure.
MIC n'écrit pas vos migrations. Alembic, les outils Node.js et le SQL propre au moteur restent sous la responsabilité du service.
MIC n'opère pas votre observabilité. Les primitives de journaux, métriques et traces sont fournies ; les backends, rétentions, alertes et SLO restent les vôtres.
MIC n'est pas votre planificateur d'infrastructure. Il fournit verrou, point de reprise, suivi et détection du silence ; l'infrastructure déclenche et supervise le processus.
MIC ne rend pas un stockage brut sûr par magie. Les vues relationnelles à portée d'organisation échouent sans contexte, mais l'application doit les injecter partout et peut ajouter des politiques en base.
MIC ne remplace ni Python, ni TypeScript, ni leurs bibliothèques. Pydantic, SQLModel, FastAPI, Node HTTP et les frameworks Node restent les briques ; MIC organise leurs frontières.

Le périmètre, le niveau de maturité et la stratégie de sortie sont documentés séparément pour éviter toute promesse implicite.

Comment savoir si MIC est pour vous¶

Vous êtes le bon public si :

vous avez plusieurs services Python, TypeScript, ou les deux, qui communiquent ;
vous voulez la même qualité minimale sans copier-coller ;
vous acceptez des contrats stricts et des tests exigeants comme contraintes de conception ;
vous voulez prouver la portabilité entre frameworks ;
vous voulez publier des contrats lisibles par les humains et les machines.

MIC vous apportera moins si :

vous avez un seul service isolé et sans frontière externe ;
vous explorez un prototype jetable dont toutes les formes vont changer ;
vous refusez les contrats stricts ou les tests des chemins d'erreur ;
vous exigez un framework sans adaptateur MIC et ne souhaitez pas écrire cette adaptation.

Commencez avec le quickstart Python ou le quickstart Node.js / TypeScript.