Ce rapport d'expérience est anonymisé (organisation ORG-1, entrepreneur E1). Il ne décrit pas une solution finie, mais un chemin : comment un idéal abstrait — « la conformité ancrée dans le .git lui-même » — est devenu, au fil d'une série de sessions de travail, une esquisse de prototype vérifiable. L'enseignement qui en ressort est moins technique que méthodologique.

Situation initiale

ORG-1 regroupe plusieurs entités juridiques : une entité à but non lucratif, une société de développement et l'entrepreneur E1 lui-même en tant qu'entrepreneur individuel. Cette constellation fait naître trois questions de conformité différentes, que l'on confond facilement :

• Aides fiscales (Forschungszulage) : quelle heure relève de quel projet ?
• Utilité publique (§ 60a AO) : dans quelle sphère se situe une activité — idéelle, Zweckbetrieb, gestion patrimoniale ou activité commerciale lucrative ?
• Régularité (GoBD/AO) : chaque pièce justificative est-elle traçable, inaltérable et complète ?

En pratique, ces questions sont souvent tranchées « au feeling » — et c'est précisément là que naissent les risques qu'un contrôle rendra visibles plus tard.

La conversation comme outil de conception

La particularité de ce projet : E1 travaille avec un agent IA local et open source comme interlocuteur. Non pas un générateur de code, mais un partenaire de dialogue qui lit le contexte existant de l'entreprise (documents, conventions, décisions déjà prises) et l'affine au fil de la conversation.

L'effet décisif n'a pas été la vitesse, mais la cohérence : chaque décision prise était immédiatement confrontée à l'architecture existante — « cela correspond-il à ce qui est déjà fixé de manière normative, ou définissons-nous quelque chose en double sans nous en apercevoir ? »

Leçon 1 : Un agent qui ne fait que générer sans vérifier l'existant produit de la redondance. Un agent qui d'abord trouve puis propose produit de la cohérence.

Le premier module : le contrôle des sphères comme call-back

Il aurait été évident d'intégrer la logique des sphères là où elle est nécessaire — dans chaque outil qui saisit des pièces justificatives. Cela ne passe pas à l'échelle et disperse la même règle à de nombreux endroits.

On a plutôt trouvé un modèle déjà existant : un registre avec des identifiants d'action/d'appel dans le répertoire TOP/.gitcover propre au mandant. Chaque étape exécutable porte une clé composite composée de deux identifiants — « ce qu'elle est » et « comment elle est exécutée ». Un outil n'a alors pas besoin de connaître l'entité concrète : il appelle un identifiant, et une résolution à travers les niveaux (du mandant spécifique à la norme générale) trouve le gestionnaire compétent.

Anfrage: "das ist ein gemeinnütziger Eintrag"
        │
        ▼
  Registry-Auflösung  (mandanten-spezifisch → normativ)
        │
        ├── gefunden  → Handler des Trägers (Sphärenprüfung § 60a)
        └── keiner    → bewusster No-Op (keine Prüfung nötig)

Le principe rappelle la résolution d'interface en programmation orientée objet : on interroge une capacité, pas un type concret. L'effet secondaire : les entités non reconnues d'utilité publique obtiennent automatiquement un « non applicable » propre — sans aucun cas particulier dans le code.

Leçon 2 : Une règle qui vaut partout doit se trouver à un seul endroit avec une interface stable — pas copiée dans chaque outil.

Le deuxième module : des artefacts de conformité reproductibles

La deuxième prise de conscience concernait le comment de la diffusion. Le savoir réglementaire — principes GoBD, principes du RGPD, délais de conservation — se trouve aujourd'hui dans des manuels que personne n'exploite. L'approche retenue ici : ce savoir devient des artefacts lisibles par machine et versionnés dans des dépôts Git.

Regulatorik  →  Katalog (maschinenlesbar)  →  Policies (ausführbar)
                                                     │
                                         Git-clone / Tool-Update
                                                     │
                                     prüfbares Ergebnis im Arbeitsverzeichnis

Le modèle n'est pas un CI/CD applicatif, mais un « CI/CD pour les faits d'entreprise » : la même mécanique de mise à jour que celle des outils logiciels diffuse ici le savoir de conformité — versionné, signable, vérifiable.

Ce que cela signifie pour la pratique

• La pièce justificative reste la pièce justificative. Les projections, pondérations et intentions derrière une affectation ne font pas partie du dossier publié — celui-ci contient le résultat, qui doit pouvoir être justifié en cas de doute.
• Séparation plutôt qu'étiquette. Une activité administrative ne devient pas éligible à un financement parce qu'on la nomme proche de la recherche. L'institution de contrôle regarde le contenu, pas le titre.
• Les consignes privées restent privées. Les appréciations personnelles, pondérations et critères d'arbitrage de la personne qui valide ne font pas partie du fonds commun versionné — elles sont conservées localement et ne sont pas citées. C'est à partir d'elles que naissent les documents de décision, qui sont ensuite justifiables. Les agents respectent ces consignes, mais ne documentent que le résultat.
• D'abord trouver, ensuite construire. Avant chaque nouveau module, la question vaut la peine : cela existe-t-il déjà — simplement sous un autre nom ?

Leçon 3 : « Du concept au prototype » ne signifie pas construire beaucoup de nouveau. Cela signifie prendre au sérieux le plan de construction existant et poser la pierre suivante au bon endroit.

Ce qui est signé est délimité dans l'index

Un autre schéma concerne la signature elle-même. Lorsqu'un document est présenté pour signature (presented), seuls les documents originaux à signer sont indexés (git add) — l'index Git indique ainsi clairement ce qui doit être signé, séparément du reste de l'état de travail. Un message de commit approprié est préparé ; le commit n'est délibérément pas effectué par l'outil (gc-docsign present …). C'est seulement ensuite que le signataire signe le commit délimité (GPG). Ainsi, « présentation » et « signature » restent proprement séparées — et la pièce justificative reste intacte.

Perspectives

L'esquisse est là : un contrôle des sphères qui se dissout là où il n'est pas nécessaire ; un corpus de règles qui voyage comme artefact par les mêmes canaux que le code. Ce n'est pas la technique qui décidera si cela devient un outil productif pour d'autres petites organisations — mais la volonté de confronter chaque hypothèse à une vérification avant qu'elle ne devienne une habitude.

Ce rapport est anonymisé (organisation ORG-1, entrepreneur E1). Il fait partie de la série Expériences & Lessons Learned.