Journal D-POAF : une approche "proof-driven" pour gouverner des systèmes IA, comparaison avec Agile et SAFe

Posté par  . Licence CC By‑SA.
Étiquettes :
1
31
jan.
2026

Sommaire

Agile et SAFe suffisent-ils pour gouverner des systèmes IA critiques ?

Ces dernières années, on a beaucoup appris à livrer du logiciel vite.

Scrum, Kanban, CI/CD, DevOps…

Puis, quand les équipes ont grossi, SAFe, LeSS, Spotify model, etc.

Franchement, sur des produits web "classiques", ça marche plutôt bien :
on itère, on déploie souvent, on corrige vite.

Mais depuis quelque temps, en travaillant sur des projets intégrant de l’IA (modèles de décision, scoring, automatisation métier), on s’est retrouvé face à un problème que ni Agile ni SAFe ne couvraient vraiment :

livrer vite ne suffit plus, il faut aussi prouver.

Prouver que ça marche.

Prouver que ça apporte de la valeur.

Prouver que c’est fiable dans le temps.

Et surtout : pouvoir expliquer qui a décidé quoi, et pourquoi.

Bref : auditabilité, traçabilité, responsabilité.

C’est ce constat qui nous a amenés à expérimenter une approche plus "proof-driven", que nous avons formalisée dans un cadre méthodologique open source appelé D-POAF (Decentralized Proof-Oriented AI Framework).

Je partage ici un retour d’expérience et une comparaison avec Agile et SAFe, histoire d’ouvrir la discussion.

Où Agile marche très bien… et où il montre ses limites

Je précise : je ne tape pas sur Agile.

Pour des équipes petites à moyennes, c’est excellent pour :
- itérer vite
- réduire le gaspillage
- rester proche du besoin
- éviter la doc inutile

Mais Agile est surtout orienté flux de livraison.

Une user story passe en Done parce que :
- le code compile
- les tests passent
- le PO valide

Très bien.

Mais si on pose des questions comme :
- peut-on démontrer objectivement la valeur produite ?
- peut-on tracer toutes les décisions importantes ?
- peut-on auditer le système 6 mois plus tard ?
- qui est responsable si le modèle dérive ou discrimine ?

… Agile n’a pas vraiment de réponse native.

Ce n’est pas un défaut : ce n’était juste pas son objectif.

SAFe : Agile à grande échelle… mais toujours centré livraison

Avec plusieurs centaines de personnes, Agile "pur" casse un peu.

Donc arrive SAFe, proposé par Scaled Agile, qui ajoute :
- coordination multi-équipes
- planning trimestriel (PI planning)
- gouvernance portefeuille
- reporting
- gestion des dépendances

Ça aide clairement à organiser le bazar.

Mais au final, ça reste :
- très process
- très organisationnel
- très déclaratif

On a plus de tableaux, plus de rôles, plus de cérémonies…

mais pas forcément plus de preuves vérifiables côté technique.

On sait qui fait quoi.

On sait moins ce qui est réellement démontré.

Pour de l’IT classique, ça passe.

Pour de l'IA critique (fraude, santé, décision automatique, conformité réglementaire), ça commence à coincer.

Pourquoi l'IA change vraiment la donne

Avec du code classique, le comportement est déterministe :
même entrée → même sortie.

Avec l'IA/ML :
- le comportement dépend des données
- les données évoluent
- le modèle dérive (drift)
- la performance peut chuter silencieusement
- les impacts peuvent être juridiques ou éthiques

Du coup la question n'est plus seulement :

"est-ce que ça marche aujourd’hui ?"

mais plutôt :

"pouvons-nous démontrer que ça marche, que ça reste fiable, et que quelqu’un en assume la responsabilité ?"

Et là, les méthodes centrées uniquement sur la vélocité montrent leurs limites.

L’idée derrière D-POAF

D-POAF n’est ni un outil, ni une librairie, ni un "framework de code".

C’est plutôt un cadre méthodologique.

L’idée de base est simple :

chaque étape du cycle de vie doit produire des preuves vérifiables.

On distingue par exemple trois types de preuves :

  • Proof of Delivery (PoD) : l’artefact existe vraiment (build, modèle, doc, etc.)
  • Proof of Value (PoV) : il apporte la valeur attendue (métriques métier mesurées)
  • Proof of Reliability (PoR) : il reste fiable dans le temps (monitoring, drift, incidents)

Si on n’a pas de preuve tangible… ce n’est pas vraiment "done".

Autre point important :

la gouvernance n’est pas "au-dessus", elle est intégrée au flux.

Chaque décision significative doit être :
- tracée
- justifiée
- attribuée à un responsable humain

Même si une IA participe à l’exécution.

Exemple concret (très simplifié)

Prenons un modèle de détection de fraude.

Approche classique :
- on entraîne
- on déploie
- on regarde la précision
- on espère que ça tient

Approche proof-driven :
- PoD : version du modèle + dataset versionné + hash
- PoV : réduction mesurée du taux de fraude réel
- PoR : monitoring drift + alertes + seuils + réévaluations périodiques
- décisions documentées : qui valide le déploiement, sur quels critères ?

Ça paraît du bon sens.

Mais dans la pratique, ce n’est presque jamais formalisé proprement.

Comparaison rapide

Aspect Agile SAFe D-POAF
Focus principal vitesse coordination preuve & gouvernance
Orientation itération organisation traçabilité
Gouvernance minimale managériale intégrée au flux
Auditabilité faible documentaire vérifiable
IA critique partiel partiel natif

L’idée n’est pas de remplacer Agile ou SAFe.

Plutôt de compléter ce qu’ils ne couvrent pas :

la dimension assurance / preuve / responsabilité.

Ce qu’on a observé sur le terrain

Quelques effets intéressants :

  • discussions plus factuelles (moins d’opinions, plus de métriques)
  • audits beaucoup plus simples
  • décisions mieux assumées
  • meilleure compréhension des risques

Et côté négatif :
- plus de rigueur
- plus de discipline
- impossible de "faire confiance au process" sans preuves

Bref, c’est moins confortable… mais plus robuste.

Pour ceux que ça intéresse

On a documenté tout ça en open source :
- spécification
- guide méthodologique
- Map conceptuelle
- terminologie
- templates

Ressources :
- https://d-poaf.org/d-poaf-framework-map/
- https://github.com/INOVIONIX/D-POAF

Ce n’est pas une méthode miracle, juste une tentative d’adresser un angle mort qu’on rencontrait souvent sur des projets IA.

Questions ouvertes

Je suis surtout preneuse de retours critiques :

  • est-ce que ça vous paraît trop lourd / bureaucratique ?
  • redondant avec ISO/ITIL/DevOps existants ?
  • utile uniquement en contexte réglementé ?
  • ou au contraire pertinent plus largement ?

Curieuse d’avoir vos avis et contre-exemples.

  • # Avis mitigé

    Posté par  . Évalué à 3 (+1/-0).

    La plupart de ce que tu écris est à la fois vrai et pertinent. Cependant, je suis incapable de comprendre la valeur ajoutée de l'IA/ML de ta lecture.
    Par ailleurs, la notion sous-jacente de preuve (surtout de valeur qui est de loin la plus intéressante) est intégrée à la plupart des méthodologies de projets et de programmes et donc loin d'être récente. Dans mon domaine (modèles quantitatifs), il existe depuis des décennies des départements et des méthodologies liées à la validation initiale et continue des modèles. Ces frameworks sont dans mon cas régulés et supervisés.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.