Périmètre, maturité et sortie¶
MIC est un socle transversal disponible pour Python et Node.js, pas une plateforme applicative totale. Cette page rend explicites trois informations qu'un adoptant doit connaître : ce qui est commun aux deux implémentations, le niveau de preuve de chacune et ce qu'il faut remplacer pour quitter MIC.
Périmètre commun¶
Les deux implémentations fournissent des briques indépendantes que le service assemble explicitement :
- contrats statiques ou gouvernés et enveloppes HTTP canoniques ;
- routes métier indépendantes du framework et adaptateurs HTTP ;
- authentification inter-service limitée par portée, client HTTP et erreurs de domaine ;
- persistance à portée d'organisation, outbox ordonnable, files, cache et verrous ;
- tâches périodiques avec point de reprise, suivi et détection du silence ;
- logs, métriques et tracing OpenTelemetry optionnels ;
- outils de test et générateur de service.
Le domaine, le schéma de données, les migrations et le déploiement restent la responsabilité du service. MIC ne masque pas les bibliothèques du runtime : Pydantic, SQLModel, SQLAlchemy, FastAPI et Litestar restent visibles en Python ; les schémas TypeScript, le stockage et Node HTTP, Express, Fastify, Hono ou NestJS restent directement accessibles en Node.js.
Niveau de preuve par runtime¶
Les deux implémentations ne revendiquent pas le même niveau de maturité.
Python¶
Preuve disponible. Utilisation par des services réels à forte densité d'intégration : HTTP, authentification, événements, outbox, observabilité et stockage opérationnel.
Limite. Cette expérience ne prouve pas le comportement d'un agrégat bitemporel complexe, d'un métamodèle modifiable à l'exécution ou de milliards de faits.
Node.js¶
Preuve disponible. Tests natifs, vérification des archives npm, installation des paquets publiés dans un projet vierge et exécution du service généré.
Limite. Ces validations ne constituent pas encore un retour de production équivalent à celui de l'implémentation Python.
Ces preuves valident la plomberie transversale dans leur périmètre. Elles ne remplacent pas la validation des invariants métier, des index, des partitions ou des performances par le produit qui possède les données. Une capacité implémentée n'est pas déclarée « éprouvée à grande échelle » sans mesure de production correspondante.
Hors périmètre actuel¶
L'API stable de MIC ne fournit pas :
- le déclencheur ou le superviseur des tâches périodiques : l'infrastructure appelle le runner Python ou Node.js et impose l'arrêt forcé ;
- une source de vérité ou un bus d'invalidation distribué pour les schémas : le registre reçoit un chargeur et l'application diffuse les changements ;
- une politique de sécurité de base de données : le stockage à portée de tenant protège la vue injectée, mais ne peut pas empêcher le code d'utiliser un stockage brut qu'on lui aurait aussi donné ;
- une livraison exactly-once, un ordre global ou une archive longue durée : l'ordre par agrégat est optionnel et le rejeu part d'une archive distincte ;
- une plateforme de déploiement, un backend d'observabilité ou une politique de rétention ;
- les règles métier, les migrations ou les modèles physiques du service.
Ces limites ne sont ni des interdits ni des promesses implicites. La
documentation d'architecture Python détaille les
contrats gouvernés, les
tâches périodiques,
l'isolation d'organisation, la
sortie SQL et les
garanties outbox. Le dépôt
mic-node documente les
contrats TypeScript et leurs adaptateurs.
Contraintes d'adoption¶
Le choix du runtime fait partie de la décision d'adoption.
Python¶
Les distributions ciblent Python 3.14. L'image de base et l'environnement cible doivent fournir cette version.
Node.js¶
Les paquets exigent Node.js 24 ou version ultérieure. Le runtime de
production et la chaîne CI doivent respecter engines.node. Les paquets
@mic-struct/* sont publiés sur le registre public npm ; leur installation ne
nécessite aucun jeton ni registre propre à MIC.
MIC ne promet pas de compatibilité avec des versions plus anciennes que celles déclarées par ses paquets. Pour un produit auto-hébergé chez des tiers, vérifiez ces contraintes avant la migration.
Comment quitter MIC¶
La sortie est progressive, module par module. Il n'existe pas de format de données propriétaire à convertir et le service conserve ses données, ses contrats métier et sa configuration de déploiement.
Sortie de l'implémentation Python¶
| Ce que votre service possède déjà | Ce qu'il faut remplacer |
|---|---|
| Modèles, schémas et règles métier | Les usages de StrictSchema, SchemaRegistry ou des enveloppes |
| Tables, migrations et SQL natif | Le cycle de vie du stockage et TenantScopedRelationalStore |
| Handlers métier neutres | L'adaptateur de HttpRouteSpec vers FastAPI ou Litestar |
| Topics, payloads et identifiants d'événements | Le store, le dispatcher et le rejeu outbox MIC |
| Déclencheurs CronJob ou systemd | L'état, les points de reprise et les métriques mic.scheduling |
| Configuration de déploiement | Les helpers auth, client et observabilité adoptés |
Sortie de l'implémentation Node.js¶
| Ce que votre service possède déjà | Ce qu'il faut remplacer |
|---|---|
| Modèles, schémas et règles métier | Les schémas, registres gouvernés ou enveloppes importés de @mic-struct/mic-core |
| Tables, migrations et SQL natif | Les stores MIC et la vue TenantScopedRelationalStore |
| Handlers métier neutres | L'adaptateur vers Node HTTP, Express, Fastify, Hono ou NestJS |
| Topics, payloads et identifiants d'événements | Les contrats outbox et queue de @mic-struct/mic-datastore |
| Déclencheurs CronJob ou systemd | Le runner, le store de planification et leurs métriques |
| Configuration de déploiement | Les paquets @mic-struct correspondants |
Une migration raisonnable remplace une frontière à la fois, conserve les tests
de contrat et vérifie les réponses publiques avant de retirer le paquet MIC
correspondant. Inventoriez les imports mic.* en Python ou @mic-struct/mic-* en
Node.js ; le code métier et les données restent ceux du service.
Critère de décision¶
Adoptez MIC pour mutualiser des garanties transversales explicites. N'attendez pas de MIC qu'il décide du modèle, de l'exploitation ou de l'échelle à la place du produit. Commencez par le quickstart Python ou le quickstart Node.js, selon le runtime que vous souhaitez évaluer.