L’autorité doit être explicite.
Personne — humain ou modèle — n’agit sans une autorité clairement définie.
À propos de BOSAI
Une architecture d’autorité pour l’IA opérationnelle
BOSAI est né d’une conviction simple : quand l’IA agit sur des systèmes réels, la question n’est pas seulement ce qu’elle peut faire, mais ce qu’elle est autorisée à faire — et comment le prouver.
L’origine
Pourquoi BOSAI existe
L’IA opérationnelle sait de plus en plus proposer des actions. Mais proposer n’est pas décider, et exécuter vite n’est pas exécuter sous contrôle.
Observer après coup ne suffit pas : quand une action a un effet externe, il faut un point de contrôle avant l’exécution, pas seulement un tableau de bord après l’incident.
BOSAI est donc pensé comme une frontière : entre ce que l’IA propose et ce qu’un humain autorise, avec une preuve qui survit à l’action.
Le projet a évolué d’une doctrine vers une architecture produit gouvernée — control plane, gates, Human GO, readback et audit — plutôt que vers un énième agent autonome.
Le fondateur
Rencontrer le fondateur
Arthur Franck
Fondateur & architecte de BOSAI
Arthur Franck est le fondateur et architecte de BOSAI. Son approche réunit architecture, technologie et conception de systèmes. Il développe BOSAI comme une architecture d’autorité pour l’IA opérationnelle : rendre les actions compréhensibles, bornées, autorisées par l’humain et vérifiables après exécution.
Son rôle couvre l’architecture produit, la doctrine de gouvernance et la conception système. Il définit les frontières entre ce que l’IA peut observer ou proposer, ce qu’un humain doit autoriser, et ce qui doit rester bloqué lorsque les preuves ou les permissions sont insuffisantes.
BOSAI est né de cette logique : une proposition n’est pas une autorisation, une simulation n’est pas une exécution et une requête réussie n’est pas un résultat vérifié.
Le déroulé
Comment le projet a démarré
- IDÉE
Problème identifié
L’IA opérationnelle agit sans frontière d’autorisation claire.
- ENREGISTRÉ
Doctrine initiale
AI prépare → BOSAI valide → Human GO → exécution contrôlée → audit.
- IMPLÉMENTÉ
Fondation du Control Plane
Chaîne incident → commande → permis, avec surfaces en lecture seule.
- IMPLÉMENTÉ
Modèle Human GO
Autorisation humaine explicite délivrant un permis borné et expirant.
- VALIDÉ LOCALEMENT
Incident Operator
Un run réel mono-incident audité (limitation de portée d’audit).
- DÉMO / CANARY
Social Operator
Une publication LinkedIn contrôlée historique, derrière Human GO.
- MVP LOCAL
Video Operator
Capture de démonstration locale déterministe, relue par un humain.
- ENREGISTRÉ
Registre Playground
Fondation de registre établie ; runtime public non encore implémenté.
- DÉMO PUBLIQUE
Démonstrations publiques
Démos synthétiques consultables sans effet externe.
- EN REVUE
Évolution de la landing
Refonte product-first disponible dans une Pull Request en brouillon ; non fusionnée et non déployée.
Chaque jalon indique un statut honnête et distinct. Rien n’est présenté comme « lancé ».
La logique
La philosophie de conception
BOSAI suit une logique de systèmes que l’on peut résumer en principes simples et exigeants.
Une proposition n’est pas une autorisation.
Ce que l’IA propose reste inerte tant qu’un humain n’a pas décidé.
Un dry-run n’est pas une exécution.
La simulation précède l’action, sans effet réel.
Une requête réussie n’est pas un résultat vérifié.
Seul un readback confirmé clôt le cycle.
La preuve doit survivre à l’action.
Chaque décision reste attribuable et auditable.
L’ambiguïté échoue fermé.
En cas de doute, aucune action externe n’a lieu.
Un modèle plus fort n’hérite pas de plus d’autorité.
La capacité ne confère jamais le droit d’agir.
Le Human GO est une décision opérationnelle bornée.
Une autorisation précise, à usage unique et expirante.
La suite
Ce que BOSAI veut devenir
Produit actuel
- chaîne de contrôle incident → commande → permis ;
- un run réel contrôlé prouvé (avec limitation) ;
- surfaces opérateur en lecture seule et démos synthétiques.
Prochains jalons
- architecture multi-opérateurs gouvernée ;
- policy gates réutilisables ;
- surfaces opérateur auditables ;
- préparation à l’évaluation et au pilote client.
Vision long terme
- Playground isolé et gouverné ;
- évolution IA gouvernée par propositions et tests isolés ;
- automatisation de workflow plus sûre et attribuable.
Les limites
Ce que BOSAI ne deviendra pas
- un agent autonome sans restriction ;
- un système de production qui se modifie seul et sans visibilité ;
- un certificat de conformité ;
- un chatbot générique ;
- un remplaçant de tous les outils d’orchestration ou d’observabilité ;
- un système qui contourne l’autorité humaine sur les actions irréversibles.
Échanger
Une invitation
Explorez un workflow gouverné, posez une question, partagez un avis ou discutez d’un cas d’usage borné.