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: 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 (+1/-1).
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 ?