Série formation — épisode 1

Pourquoi gouverner les décisions IA : proposer, décider, prouver

Publié le 17 octobre 2026 · Talentys · ~10 minutes de lecture

Cette série en douze épisodes explique, en français clair, comment Arca Suite gouverne les décisions prises avec vos données et votre IA. Premier épisode : la doctrine. Deux précisions honnêtes avant de commencer : Arca Suite est en V1.0, en production, sans encore de clients à citer ; et l'exemple utilisé plus bas est explicitement fictif.

1. Le problème n'est pas le modèle, c'est la décision

Les débats autour de l'IA en entreprise tournent presque toujours autour des modèles : lequel est le plus précis, le moins cher, le mieux aligné. Mais dans une organisation, personne ne rend de compte d'un modèle — on rend compte d'une décision. Un crédit accordé ou refusé. Une ligne de production arrêtée. Un dossier médical partagé. Une commande fournisseur validée. Derrière chacune de ces décisions, il y a de plus en plus souvent une proposition générée par une machine.

Or une proposition de machine n'a pas de statut. Elle n'est ni responsable, ni opposable, ni auditable en l'état. Tant qu'on ne sait pas qui a transformé cette proposition en décision, sur quelle base, et avec quel droit, l'IA reste un générateur de suggestions dont personne ne répond. C'est précisément ce qui bloque tant de projets au stade de la preuve de concept : pas la technologie, mais la question « qui est responsable si l'on signe ? ».

Gouverner les décisions IA consiste à donner un statut à chaque étape de ce passage de la suggestion au fait accompli. Arca Suite le fait avec une doctrine en trois verbes : proposer, décider, prouver.

2. Proposer — la place exacte de l'IA

Dans Arca Suite, l'IA fait ce qu'elle sait faire : lire massivement, rapprocher, synthétiser, recommander. Elle travaille sur vos données structurées dans un graphe gouverné — construit par ArcaQ sur une fondation OpenMetadata — et elle produit une proposition : un texte, un score, un choix recommandé, toujours accompagné de ses sources et de son niveau de confiance.

Deux règles encadrent cette étape. D'abord, la proposition est probabiliste par nature ; la plateforme l'affiche comme telle, sans la déguiser en certitude. Ensuite, une proposition n'a aucun pouvoir d'exécution : elle entre en quarantaine et attend d'être examinée. La machine suggère ; elle ne décide pas. Ce simple partage des rôles change tout : il cesse d'être possible qu'une action soit déclenchée « parce que le modèle l'a dit ».

3. Décider — une autorité humaine, nommée et horodatée

Une décision n'existe que si un humain légitime la prend. Arca Suite exige donc, avant toute promotion d'une proposition en décision, une double validation humaine : deux personnes identifiées, aux rôles distincts, qui examinent la proposition, son contexte et ses sources. Le refus n'est pas un échec du système — c'est une décision de première classe, enregistrée avec le même soin qu'une approbation.

Ce point rejoint deux réflexes familiers des organisations sérieuses : la séparation des tâches (celui qui prépare ne signe pas) et le contrôle à quatre yeux. Il rejoint aussi le sens de l'article 14 du règlement européen sur l'IA : le contrôle humain doit être effectif, pas honorifique. Un bouton « approuver » cliqué en trois secondes par habitude n'est pas du contrôle ; une revue structurée, avec le contexte sous les yeux et un nom en bas de page, si.

Et quand la décision est prise, elle est scellée : signée, horodatée, rattachée à la proposition d'origine et à ses sources. C'est ce sceau — porté par ArcaX et ses Decision Contracts — qui autorise l'exécution. Sans décision scellée valide, aucune action ne part.

4. Prouver — la mémoire institutionnelle de la décision

La troisième étape est celle qu'on oublie jusqu'au jour où un auditeur, un régulateur ou un conseil d'administration pose la question : « pourquoi avez-vous fait ça ? ». Dans la plupart des organisations, la réponse prend des semaines d'archéologie : e-mails, tickets, captures d'écran, témoignages. Avec Arca Suite, la preuve est un sous-produit du fonctionnement : qui a proposé, sur quelles sources, avec quel niveau de confiance, qui a relu, qui a validé, quand, et ce qui a été exécuté ensuite. Le dossier est reconstructible en minutes, parce qu'il a été constitué au fil de l'eau — nous y reviendrons en détail dans l'épisode consacré au DecisionRecord.

5. Un exemple concret — explicitement fictif

Cet exemple est une fiction pédagogique, sans rapport avec un client réel : Arca Suite n'en a pas encore. Imaginons une banque régionale, « Banque du Canal », qui reçoit une demande de crédit professionnel de 180 000 €. Le moteur d'analyse — branché sur le graphe de connaissances de la banque — produit une proposition : « accord recommandé », assortie des bilans repris dans le graphe, d'un score de confiance et d'un point d'attention sur la trésorerie du dernier exercice.

La proposition entre en quarantaine. Une analyste crédit l'examine : elle vérifie les sources, corrige une donnée de trésorerie mal rafraîchie dans le graphe, puis soumet son avis. Un directeur d'agence, second regard obligatoire, constate la correction, interroge le point d'attention et approuve avec une condition : une clause de réexamen à six mois. La décision est scellée — deux noms, un horodatage, la proposition d'origine et sa correction. Six mois plus tard, le réexamen n'a pas besoin d'enquête : tout le contexte de la décision initiale est là, intact.

Ce scénario est jouable tel quel sur la démo publique de la plateforme : le walkthrough de bout en bout montre ce même trajet, de la proposition au sceau, sur les écrans réels de production.

7. Pour aller plus loin

Voir la doctrine en fonctionnement : la démo walkthrough et les vidéos enregistrées en production. Situer Arca Suite face aux autres approches : le comparatif honnête avec Palantir AIP et Credo AI. Et l'écosystème qui porte la plateforme : Talentys, ArcaQ et ArcaX.

Épisode suivant de la série : ArcaQ — intelligence des métadonnées, lignage et OpenMetadata. Tous les épisodes.