Yvan Dervillier
← Projets

Gouvernance IA · Produit open source

hub-ia

Un portail open source pour qu'une PME adopte l'IA avec méthode, forme ses équipes et documente ses mesures AI Act.

Rôle
Conception produit, spécification, pilotage des agents, revue
Période
Sept. 2026 → en cours
Statut
Prototype avancé · open source
01 Le hub d'une équipe en mode édition : cartes, glisser-déposer, thème clair et sombre.
02 La priorisation des tâches avec le score en direct, puis le choix du levier.
03 Le registre AI Act : statut par personne, chaîne d'intégrité, export imprimable.

En bref

  1. Problème : les PME adoptent l'IA sans méthode ni gouvernance, et doivent pourtant prouver la formation de leurs équipes (AI Act, art. 4).
  2. Ce que j'ai fait : cadré le produit, écrit la spec et les règles d'agents, puis piloté sa construction par des agents IA jusqu'au déploiement.
  3. Résultat : un prototype complet en un seul binaire Go (adoption, catalogue gouverné, registre chaîné SHA-256), avec CI et détection de secrets.

Contexte

Dans une PME de 10 à 300 personnes, l’IA arrive par le bas : chacun teste ses outils, colle parfois des données sensibles dans un chatbot, et personne ne sait où l’IA fait vraiment gagner du temps. En parallèle, l’AI Act (article 4) demande de former les équipes et de pouvoir le montrer.

Les suites des éditeurs couvrent l’outillage. Il manque la méthode, la gouvernance et la preuve de formation, ancrées dans l’entreprise.

Ce que fait le produit

  • Hub d’équipe : un onglet par équipe, cartes éditables en place, journal d’audit de chaque modification.
  • Méthode d’adoption : cartographier les tâches, repérer les irritants, prioriser avec score = fréquence × durée × volume, choisir le bon levier (assistant, agent, fonctionnalité produit… ou ne rien changer), puis mesurer les heures gagnées.
  • Gouvernance : catalogue des outils IA autorisés (propriétaire, périmètre de données, classification), charte, matrice données × outils, et déclaration anonyme des outils non autorisés pour rendre le shadow AI visible sans le punir.
  • Registre de maîtrise de l’IA : parcours en 4 niveaux, auto-déclaration validée par un administrateur, exports CSV et imprimable.

Architecture

mécanique

analytique

à industrialiser

aucun gain

Cartographier les tâches

Repérer les irritants

Prioriser : fréquence × durée × volume

Choisir le levier

Agent encadré

Assistant

Fonctionnalité produit

Garder en l'état

Mesurer les heures gagnées

Catalogue IA gouverné

Parcours 4 niveaux

Validation admin

Registre chaîné SHA-256

Un binaire Go embarque PocketBase, les gabarits et les assets. Le navigateur reçoit du HTML partiel (htmx). La logique métier vit dans deux paquets testés isolément (method, register) et les droits sont appliqués côté serveur.

Méthode agentique

  • Spec d’abord : vision, rôles, modèle de données, écrans et périmètre par version sont figés avant le code. Positionnement, cadre juridique et veille sont documentés à part.
  • Le plan vit dans des fichiers : plan à cocher, journal de progression et fichier de reprise permettent à un agent de reprendre exactement où le précédent s’est arrêté.
  • Règles écrites pour les agents (AGENTS.md) : interdits explicites (aucune entreprise réelle, aucun secret, jamais « conforme AI Act »), zones protégées (CI, déploiement), format de preuve exigé dans chaque PR. Les mêmes règles valent pour Claude, Codex ou Gemini.
  • L’humain garde la main : les agents n’ont pas accès au cluster, le déploiement reste un geste humain.

Décisions

Les choix qui structurent le projet, avec l'option écartée et la raison.

  1. D1 Un binaire + SQLite

    Choix
    Go avec PocketBase embarqué, gabarits HTML et htmx, un seul fichier de données.
    Écarté
    Stack SaaS classique (SPA + API + base managée).
    Pourquoi
    La cible n'a pas d'équipe plateforme : installer, sauvegarder et mettre à jour doit tenir en une commande.

  2. D2 Enregistrer des mesures, pas des personnes

    Choix
    Le registre trace les formations suivies et validées, jamais une note individuelle.
    Écarté
    Score de maîtrise par salarié.
    Pourquoi
    Éviter un outil de surveillance, et rester honnête sur ce que l'AI Act demande vraiment.

  3. D3 Ne pas refaire les outils IA

    Choix
    Pas de chat, pas de RAG, pas de moteur de workflows : le produit pointe vers les outils existants.
    Écarté
    Plateforme tout-en-un.
    Pourquoi
    Le manque est dans la méthode et la gouvernance, pas dans l'outillage. Le périmètre reste tenable.

  4. D4 Intégrité par chaîne d'empreintes

    Choix
    Chaque entrée du registre inclut l'empreinte SHA-256 de la précédente.
    Écarté
    Signature électronique ou registre externe.
    Pourquoi
    Toute modification a posteriori devient visible, sans dépendance ni coût.

Résultats

État du dépôt au 15 oct. 2026.
MesureAvantAprès
Piliers fonctionnels livrés·4 / 4
Migrations de schéma versionnées·5
Contrôles CI (dont détection de secrets)·8
Build front (Node)requis dans une stack SPAaucun

Limites et suite

  • Aucun utilisateur réel à ce jour : la valeur de la méthode reste à mesurer en conditions réelles.
  • Les tests navigateur ont été faits pendant le développement mais ne sont pas encore automatisés en CI.
  • Le cadre juridique est documenté, pas validé : une relecture par un avocat est prévue avant toute communication.

Ce que ce projet démontre

  • Cadrer un produit à partir d'une veille structurée : problème, positionnement, non-objectifs
  • Traduire une exigence réglementaire (AI Act art. 4) en mécanisme concret et honnête
  • Piloter des agents de façon reproductible : spec, règles d'agents, reprise de session, preuves en PR
  • Livrer simple à exploiter : un binaire, un fichier SQLite, CI avec détection de secrets