SHAPER OS : un cadre solide pour des systèmes qui évoluent

Un système immunitaire cognitif

Préserver les repères qui nous permettent de comprendre et d’agir, tout en gardant la liberté de les questionner : c’est l’intention du système immunitaire cognitif. Le contre-regard, la vérification et la correction aident à repérer une hypothèse fragile, à examiner ce qui tient et à faire évoluer notre cadre de pensée. Les mécanismes de contrôle sont eux aussi soumis à cet examen.

Faire dialoguer des regards différents

Des agents issus de fournisseurs différents peuvent apporter des habitudes de raisonnement et des angles morts différents. Leur contre-regard permet de confronter les hypothèses et les résultats, y compris ceux de l’auteur du cadre. La diversité ne suffit pas à garantir la justesse : il faut examiner les arguments et vérifier les effets réels.

Apprendre sans rester figé

Une expérience difficile nous apprend quelque chose ; elle ne ferme pas toutes les possibilités à venir. Nous conservons les faits et examinons si les causes de l’échec sont encore présentes. Quand les conditions changent, une nouvelle approche peut être essayée dans un périmètre adapté. On peut ainsi apprendre, improviser et s’adapter sans perdre ses repères.

Des intentions durables, des réalisations qui évoluent

Le dépôt SHAPER OS décrit les intentions, les principes, les rôles et les relations ; le code appartient aux réalisations séparées. De futurs agents pourront proposer des façons plus simples ou plus sûres de réaliser ces intentions. Ce qui fonctionne reste versionné et réutilisable. Chaque évolution doit préserver les données, respecter le mandat et être vérifiée ; les principes peuvent eux aussi évoluer par une décision humaine explicite.

Pilotage métier au quotidien

Vous pilotez votre activité, vos clients et vos dossiers. Nous préparons et adaptons les outils avec vous, sans vous demander d’administrer les serveurs.

Architecture et gouvernance technique

Exécution conteneurisée, contrôle des accès, topologie des modèles d’IA, stratégie de sauvegarde et reprise après sinistre. Détails complets dans la section « sous le capot ».

L’autonomie contrôlée

SHAPER OS permet à des systèmes de travailler avec une autonomie encadrée. Des agents IA y observent ce qui se passe, effectuent les tâches prévues et signalent les anomalies ; ils ne réparent que ce que leur mandat autorise, et le reste remonte au niveau supérieur. L’humain garde le contrôle dès qu’une action dépasse ce que le système est autorisé à faire.

Les univers autonomes

Un univers rassemble les unités fonctionnelles qui réalisent une activité : applications, services et agents, avec leurs règles et leurs dépendances. Chaque unité fonctionnelle possède sa propre base de données. Un espace, lui, regroupe les univers d’une même entité.

L’orchestration déclarative

On décrit ce qui doit exister, ses dépendances et les opérations autorisées. Le gouverneur tient cet état souhaité ; les makers réalisent les opérations sur les machines et rapportent les résultats. SHAPER OS définit le cadre dans lequel ces outils travaillent.

Unité de responsabilité & supervision parent

Les responsabilités sont définies pour chaque univers. L’agent entretient les composants dans son mandat ; les changements profonds passent par le parent. Le parcours prévu prépare une version isolée, vérifie les changements, puis autorise une mise en production avec une possibilité de retour arrière.

Architecture fractale récursive

Un univers peut en gérer d’autres (Brique → Univers → Univers parent → Univers racine) ; les machines sont l’endroit où tournent les univers, pas un niveau de la gestion. Chaque niveau applique le même cycle invariant : intention → matérialisation → exécution → observation → preuve → réparation → validation → promotion.

L’agent de boutique : autonome dans son cadre

Le commerçant pilote sa boutique avec Helm, dans sa juridiction : « Mets à jour mes produits », « Analyse mes erreurs », « Prépare la nouvelle version ». L’agent connaît l’environnement de sa boutique, quelle qu’en soit la technologie, ses outils et ses limites. Si une action est risquée ou dépasse son cadre, elle est escaladée au parent.

Le shop manager : univers parent des boutiques

Dans son espace, le client pilote avec Helm un univers de gestion relié à ses boutiques. Ce manager observe leur état, reçoit leurs alertes et coordonne les changements autorisés. Les modifications profondes passent par le parent et sont réalisées par les makers.

Le SaaS multi-clients : univers grand-parent

Le SaaS joue le rôle de gouverneur : il tient le registre de ce qui doit exister, selon les commandes validées et les règles du service. Les makers consultent ce registre, réalisent les opérations autorisées et rapportent leurs résultats. La même logique se retrouve à plusieurs échelles.

Une seule architecture, toutes les technologies

Boutique clé en main, service hébergé ou application sur mesure : on ne construit pas un système séparé par technologie. SHAPER fournit le cadre commun et les conventions ; chaque univers apporte sa spécialisation. Le socle public n’embarque volontairement aucun produit tiers : c’est ce qui lui permet d’en porter plusieurs.

Un pilier, puis votre métier

Le même socle sert un artisan, une PME, une association. Ce qui change, c’est l’outil façonné dessus : relances, stock, boutique, membres, planning.

Un assistant connecté à vos données

Un agent IA intégré à votre contexte opérationnel peut exécuter des tâches métier : classifier, relancer, préparer, notifier. Les interfaces s’adaptent à vos usages réels.

Pas un seul cloud, pas un seul modèle

On choisit avec vous où vont les données : chez un fournisseur, en hybride, ou chez vous. Un modèle local est possible quand le dossier l’exige. Les choix d’architecture sont guidés par vos contraintes réelles.

Vous restez propriétaire

Le code de votre application vous est cédé — l’assemblage des briques open source et la spécialisation programmée pour vous ; l’hébergement, l’export et la politique de sauvegarde sont écrits au contrat. On peut l’opérer pour vous, ou vous transmettre la main. Le façonnage est la méthode ; Shaper OS est le modèle d’exploitation dessous.

Un espace propre à chaque organisation

L’espace regroupe vos univers. Dans chacun, les unités fonctionnelles ont leurs propres données et leurs accès définis. Le projet précise les frontières entre organisations et les contrôles qui doivent vérifier ce cloisonnement.

Vos secrets dans votre coffre

Mots de passe et clés d’accès sont chiffrés dans un coffre propre à l’univers. La clé qui l’ouvre ne voyage pas avec lui, et la sauvegarde a sa propre clé.

La sortie écrite dès l’entrée

Le modèle d’univers prévoit une déclaration de fin de vie : ce que deviennent vos données à la fin, et ce qui vous est remis. Le format de sortie se fixe au contrat du projet.

Des modèles d’IA interchangeables

Aucun modèle n’est gravé dans le socle : on retient ceux qui fonctionnent depuis votre machine, et on en change quand le paysage bouge. Ce qui est sensible peut rester sur un modèle local, ou chez un fournisseur que vous acceptez.

Libre de reprendre la main

Des technologies courantes, une documentation livrée, et un socle public qu’une autre équipe compétente peut lire et redéployer.

Ce que la conception ne fait pas seule

Quand un service extérieur est utilisé, par exemple la reconnaissance de la voix pendant un appel, les données concernées y passent, et c’est écrit. L’hébergement, l’export et les sauvegardes se fixent au contrat de chaque projet.

Contrat d’exécution

Linux standardisé et conteneurisation (Podman). Déployable sur serveur cloud, VPS, machine dédiée sur site ou poste Linux isolé. L’exploitation peut être opérée par nos soins ou gérée par vos équipes.

Indépendance des modèles et des agents

Chaque tâche précise ses besoins : qualité du résultat, temps de réponse, contexte nécessaire et budget. Les modèles sont évalués sur ces tâches, depuis l’environnement retenu. Le choix peut privilégier un coût plus faible, une meilleure performance ou un plafond budgétaire. Si aucun modèle ne satisfait les exigences, le système demande une décision au lieu de choisir silencieusement.

Cas 1 : images déjà en cache

Les images de conteneurs sont déjà présentes (cache local ou registry). Le socle technique se déploie sans reconstruire les images ; vient ensuite la restauration des données.

Cas 2 : images à récupérer ou reconstruire

Machine neuve ou registry distant : le temps d’acquisition et de construction des conteneurs dépend de la bande passante et de la puissance machine avant le démarrage.

Cas 3 : restauration des données métier

Les bases de données et les volumes sont restaurés, puis leur cohérence et le fonctionnement des services sont vérifiés. La durée dépend du volume, du stockage, du réseau et des opérations de restauration.

Cinq niveaux de sauvegarde

Une copie du conteneur de l’univers ; des archives des volumes persistants ; des exports des bases de données ; le code versionné ; une copie hors site chiffrée. Ces protections couvrent des besoins différents et se complètent. Le parcours de restauration est défini et testé pour l’environnement retenu.

Rien de vous n’est publié

Les données, les secrets et les configurations propres aux clients restent hors des dépôts publics. Le code commun prévoit une configuration séparée pour chaque déploiement. Des contrôles de publication recherchent les informations qui ne doivent pas être exposées.

Une documentation utilisable par les humains et les agents

Le dépôt s’adresse à deux lecteurs. Les humains montent par niveaux, du dirigeant à l’architecte. Les agents IA sont orientés selon leur capacité : les modèles puissants reçoivent les principes dont tout se déduit, les modèles rapides reçoivent des étapes littérales et des points d’arrêt explicites. La documentation est elle-même mise à l’épreuve : un agent qui n’a jamais vu le système doit pouvoir agir sans qu’un humain lui explique quoi que ce soit. Sinon, c’est la documentation qui est en défaut.