Merci pour ton retour, je te rejoins sur le côté formalisation, il y'a clairement pas mal de bon sens déjà connu derrière tout ça. Cela dit, il y'a aussi pas mal de nouveautés et de points différenciants:
- une approche orientée preuve, avec artefacts vérifiables "cryptographiquement" (hash, merkle trees, signatures..) afin d'attester rapidement l'intégrité des décisions et productions sur tout le cycle de vie.
- une logique décentralisée, zero-trust, en gros pas d'autorité centrale qui "fait foi", et c'est justement pour favoriser transparence et auditabilité.
- une gouvernance vivante intégrée en continu et "tracée", pas seulement du pilotage isolé ou après coup.
- une structuration explicite aussi du travail humain + IA, qui décide, qui valide,
quelles responsabilités, quelles charges, quels indicateurs. Avec l'automatisation croissante, il est utile de rendre ces interactions beaucoup plus tangibles et maîtrisés.
L'idée est moins nouvelle méthode miracle, que rendre ces garanties natives, surtout dans des systèmes IA de plus en plus automatisés et autonomes.
Je te rejoins sur la partie contexte réglementé, plus on automatise, plus on a besoin de consigner ce qui est produit. Sinon on perd vite visibilité et contrôle du système.
Pour l'IA, c'est mon côté trop "doc d'architecte" qui écrit en listes et tableaux.
Merci pour ce retour pertinent et je suis d'accord sur ce point, dans les domaines "modèles quantitatifs", la validation de valeur, existe depuis longtemps avec des cadres régulés. D-POAF ne prétend pas réinventer ça.
Le point que j'essaie de clarifier, c'est que le framework vise surtout l'ingénierie logicielle où l'IA est "dans la boucle" du système (pas en tant que modèle). Dans ce contexte, on voit arriver dans l'IT généraliste des comportements typiques du ML, d'où mon exemple dans l'article.
Pour précision, dans D-POAF, la notion de "preuve" n'est pas seulement un processus de validation avec métriques, business outcomes etc.. c'est une structuration transverse qui relie artefacts + décisions + critères de valeur + responsabilité humaine/IA, de façon traçable sur tout le cycle de vie logiciel.
En particulier, la proof of value n’est pas uniquement "le modèle a de bonnes métriques", mais "le système apporte la valeur terrain attendue, attachée aux décisions et aux artefacts techniques qui l'ont produite, traçable et vérifiable". En gros, cet artefact / système produit cette valeur mesurée, et voici les preuves + qui l'a validé. si tu veux plus de précisions, je te met directement le lien vers le canonical et guide. https://d-poaf.org/resources/D-POAF-Canonical-V1.pdf https://d-poaf.org/resources/D-POAF-guide-V3.pdf
Curieux d'ailleurs, vous utilisez quel type de méthodo côté quant/modèles pour gérer la validation initiale et continue que tu as indiquées ?
[^] # Re: Formalisation de ce qui existe déjà … mais c’est aussi la base de l’Agile
Posté par SaraIhsine . En réponse au journal D-POAF : une approche "proof-driven" pour gouverner des systèmes IA, comparaison avec Agile et SAFe. Évalué à 2 (+2/-0).
Merci pour ton retour, je te rejoins sur le côté formalisation, il y'a clairement pas mal de bon sens déjà connu derrière tout ça. Cela dit, il y'a aussi pas mal de nouveautés et de points différenciants:
- une approche orientée preuve, avec artefacts vérifiables "cryptographiquement" (hash, merkle trees, signatures..) afin d'attester rapidement l'intégrité des décisions et productions sur tout le cycle de vie.
- une logique décentralisée, zero-trust, en gros pas d'autorité centrale qui "fait foi", et c'est justement pour favoriser transparence et auditabilité.
- une gouvernance vivante intégrée en continu et "tracée", pas seulement du pilotage isolé ou après coup.
- une structuration explicite aussi du travail humain + IA, qui décide, qui valide,
quelles responsabilités, quelles charges, quels indicateurs. Avec l'automatisation croissante, il est utile de rendre ces interactions beaucoup plus tangibles et maîtrisés.
L'idée est moins nouvelle méthode miracle, que rendre ces garanties natives, surtout dans des systèmes IA de plus en plus automatisés et autonomes.
Je te rejoins sur la partie contexte réglementé, plus on automatise, plus on a besoin de consigner ce qui est produit. Sinon on perd vite visibilité et contrôle du système.
Pour l'IA, c'est mon côté trop "doc d'architecte" qui écrit en listes et tableaux.
[^] # Re: Avis mitigé
Posté par SaraIhsine . En réponse au journal D-POAF : une approche "proof-driven" pour gouverner des systèmes IA, comparaison avec Agile et SAFe. Évalué à 0 (+2/-2).
Merci pour ce retour pertinent et je suis d'accord sur ce point, dans les domaines "modèles quantitatifs", la validation de valeur, existe depuis longtemps avec des cadres régulés. D-POAF ne prétend pas réinventer ça.
Le point que j'essaie de clarifier, c'est que le framework vise surtout l'ingénierie logicielle où l'IA est "dans la boucle" du système (pas en tant que modèle). Dans ce contexte, on voit arriver dans l'IT généraliste des comportements typiques du ML, d'où mon exemple dans l'article.
Pour précision, dans D-POAF, la notion de "preuve" n'est pas seulement un processus de validation avec métriques, business outcomes etc.. c'est une structuration transverse qui relie artefacts + décisions + critères de valeur + responsabilité humaine/IA, de façon traçable sur tout le cycle de vie logiciel.
En particulier, la proof of value n’est pas uniquement "le modèle a de bonnes métriques", mais "le système apporte la valeur terrain attendue, attachée aux décisions et aux artefacts techniques qui l'ont produite, traçable et vérifiable". En gros, cet artefact / système produit cette valeur mesurée, et voici les preuves + qui l'a validé. si tu veux plus de précisions, je te met directement le lien vers le canonical et guide.
https://d-poaf.org/resources/D-POAF-Canonical-V1.pdf
https://d-poaf.org/resources/D-POAF-guide-V3.pdf
Curieux d'ailleurs, vous utilisez quel type de méthodo côté quant/modèles pour gérer la validation initiale et continue que tu as indiquées ?