Objectif :

démontrer comment l’IA a été utilisée comme outil d’assistance tout au long du P13, avec traçabilité des prompts, propositions, vérifications humaines/techniques et décisions finales.

Principe :

l’IA propose ou assiste ; toute proposition importante est vérifiée avant d’être conservée, corrigée ou écartée. La décision finale reste humaine.

ID Tâche Objectif Outil IA Prompt Proposition IA Vérification humaine / technique Résultat Décision Limite
IA-01 3.1 - Contrôle qualité ERP Générer le schéma Pandera ERP Gemini Je travaille sur erp_poc, copie non modifiée du fichier ERP du P6. Je veux maintenant créer un seul schéma Pandera couvrant l’ensemble des règles ERP, et non des contrôles colonne par colonne dispersés. Règles à implémenter : product_id : entier, non nul, unique ; onsale_web : entier, non nul, valeurs autorisées 0 ou 1 ; price : numérique, non nul, valeur >= 0 ; stock_quantity : entier, non nul, valeur >= 0 ; stock_status : non nul, valeurs autorisées instock ou outofstock ; purchase_price : numérique et non nul ; règle de cohérence entre stock_quantity et stock_status : si stock_quantity > 0, statut attendu = instock si stock_quantity == 0, statut attendu = outofstock. Contraintes : utiliser pandera.pandas as pa ; utiliser un DataFrameSchema ; ne modifier aucune valeur de erp_poc ; ne corriger automatiquement aucune anomalie ; utiliser lazy=True afin de récupérer toutes les non-conformités en une seule validation ; en cas d’échec, afficher un tableau lisible à partir de failure_cases ; ne passer ni à Liaison ni à Web. Le but est uniquement de détecter et tracer les anomalies ERP existantes. Gemini a généré un schéma Pandera et placé lazy=True dans DataFrameSchema. L’erreur montre que lazy=True a été utilisé au mauvais endroit ; il doit être appliqué lors de validate(). Échec à l’exécution : TypeError: DataFrameSchema.__init__() got an unexpected keyword argument 'lazy'. Corriger le code puis effectuer un nouvel essai. Le code généré par l’IA doit être vérifié avant d’être retenu.
IA-02 3.1 - Contrôle qualité ERP Corriger et rendre lisible la validation Pandera du fichier ERP ChatGPT Corrige le code de validation Pandera du fichier ERP dans mon POC P13. Le code doit fonctionner dans Colab, utiliser erp_poc sans modifier les données, détecter toutes les anomalies en une seule validation et afficher les résultats de manière simple et lisible. Je veux distinguer les anomalies par colonne des incohérences entre stock_quantity et stock_status Replacer lazy=True dans validate(), rendre erp_schema explicite, séparer anomalies par colonne et cohérence stock/statut Exécution dans Colab sur erp_poc, comparaison avec les anomalies connues du P6 3 prix négatifs, 2 stocks négatifs, 2 incohérences stock/statut Retenir cette structure de validation pour ERP Pandera détecte les non-conformités mais ne décide pas de leur correction
IA-03 3.1 - Contrôle qualité Web Construire un contrôle global du fichier Web avant les jointures ChatGPT À partir de web_poc et des problèmes déjà repérés dans le P6, construis un contrôle reproductible avant jointure. Vérifie les SKU manquants, les doublons, les formats inhabituels, les lignes totalement dupliquées et les lignes sans SKU contenant éventuellement des informations. Utilise Pandera pour définir les règles et Pandas pour afficher des résultats simples. Ne modifie aucune donnée. Créer un contrôle Pandera pour les règles principales et utiliser Pandas pour afficher séparément les anomalies de façon lisible. Exécution dans Colab et comparaison avec le P6. Le contrôle retrouve 85 SKU manquants, les doublons, 2 formats non standards et les doublons complets. Premier contrôle non fiable pour distinguer les informations réellement utilesLe contrôle Web fonctionne globalement, mais le contrôle des lignes sans SKU doit être amélioré avant d’être retenu. Retenir la structure générale Pandera + Pandas pour Web et traiter séparément le problème des lignes sans SKU. Certaines anomalies nécessitent une interprétation métier et ne peuvent pas être décidées uniquement par le code.
IA-04 3.1 - Contrôle qualité Web Vérifier correctement quelles lignes sans SKU contiennent réellement des informations utiles ChatGPT Le premier contrôle indique que les 85 lignes sans SKU contiennent des informations. Vérifie si ce résultat est réellement pertinent, notamment parce que certaines colonnes contiennent des valeurs techniques comme 0. Propose une façon plus juste de distinguer les valeurs par défaut des informations réellement renseignées, sans modifier les données. Ne pas considérer automatiquement toute valeur 0 comme une information utile et revoir le contrôle des lignes sans SKU. Exécution du contrôle corrigé dans Colab. Le résultat a été vérifié directement dans les lignes affichées. Le contrôle corrigé identifie 2 lignes sans SKU contenant réellement des informations utiles. Retenir le contrôle corrigé et ne pas supprimer automatiquement ces 2 lignes. Elles devront être examinées dans la suite du traitement. Les valeurs 0 ont été considérées ici comme des valeurs techniques par défaut pour identifier les lignes réellement renseignées. Cette règle ne doit pas être appliquée automatiquement à tous les contextes métier.
IA-05 3.1 - Contrôle qualité Liaison érifier les clés product_id et id_web avant les jointures et distinguer les valeurs manquantes des vrais doublons ChatGPT À partir de liaison_poc et des contrôles déjà présents dans le P6, construis un contrôle qualité reproductible avant jointure. Vérifie les valeurs manquantes, les doublons et l’unicité de product_id et id_web, les formats particuliers et les lignes totalement dupliquées. Pour id_web, distingue les valeurs manquantes des vrais doublons parmi les valeurs renseignées. Utilise Pandera pour formaliser les règles et Pandas pour afficher des résultats lisibles. Ne modifie aucune donnée. ChatGPT a proposé un schéma Pandera pour contrôler product_id et id_web, avec un contrôle séparé de l’unicité des id_web renseignés, puis des contrôles Pandas pour afficher les valeurs manquantes, doublons, formats particuliers et lignes dupliquées. Exécution dans Colab sur liaison_poc et comparaison avec les constats du P6. Le P6 indiquait id_web.is_unique == False. Le nouveau contrôle montre qu’il n’y a en réalité aucun doublon parmi les id_web renseignés ; les valeurs manquantes doivent être analysées séparément. product_id : 0 manquant et 0 doublon ; id_web : 91 manquants, 0 doublon parmi les valeurs renseignées ; 3 formats particuliers ; 0 ligne totalement dupliquée Retenir les contrôles Liaison pour le POC et utiliser cette distinction lors du test des jointures en 3.2 Le contrôle identifie les anomalies de clés mais ne permet pas encore de savoir leur impact réel sur les jointures avec Web
IA-06 3.2 — Gestion des anomalies Tester si les corrections manuelles de 4039 et 4885 peuvent être remplacées par une règle générale ChatGPT À partir des 2 incohérences stock/statut détectées en 3.1, propose un test sur une copie de erp_poc pour remplacer les corrections spécifiques par ID du P6 par une règle générale : si stock_quantity > 0, le statut attendu est instock ; si stock_quantity == 0, le statut attendu est outofstock. Compare les incohérences avant/après et affiche uniquement les lignes réellement modifiées. Ne modifie pas erp_poc et ne traite pas les stocks négatifs. Créer une copie erp_gestion_test, mesurer les incohérences avant traitement, appliquer la règle générale, mesurer à nouveau les incohérences et afficher les lignes modifiées Exécution dans Colab et comparaison des résultats avant/après 2 incohérences avant, 0 après ; seules les lignes 4039 et 4885 ont été modifiées Retenir la règle générale dans le POC à la place des corrections spécifiques par ID La règle reprend la logique déjà utilisée dans le P6 ; elle ne traite pas les stocks négatifs et ne constitue pas à elle seule une validation métier externe
IA-07 3.2 — Gestion des anomalies Tester une gestion sûre des prix négatifs quand la bonne valeur n’est pas connue. ChatGPT À partir des 3 prix négatifs détectés en 3.1, propose un test permettant de les isoler pour validation métier sans modifier erp_poc. Vérifie que les 3 anomalies sont identifiées, qu’aucune autre ligne n’est isolée et que les prix d’origine restent inchangés. Créer une copie de erp_poc, détecter price < 0, créer une table anomalies_prix, ajouter la décision “Validation métier requise” et vérifier que les valeurs originales sont conservées. Exécution dans Colab et contrôle du nombre de lignes isolées et de la conservation des prix. 3 anomalies isolées ; prix originaux conservés. Retenir l’isolement avec validation métier, sans correction automatique. Le contrôle ne permet pas de connaître la bonne valeur du prix.
IA 08 3.2 — Gestion des anomalies Tester une gestion sûre des stocks négatifs quand la quantité correcte n’est pas connue ChatGPT À partir des 2 stocks négatifs détectés en 3.1, propose un test permettant de les isoler pour validation métier sans modifier erp_poc. Vérifie que les 2 anomalies sont identifiées, qu’aucune autre ligne n’est isolée et que les quantités d’origine restent inchangées. Créer une copie de erp_poc, détecter stock_quantity < 0, créer une table anomalies_stock, ajouter la décision « Validation métier requise » et vérifier que les quantités originales sont conservées Exécution dans Colab et vérification du nombre de lignes isolées et de la conservation des stocks 2 anomalies isolées : produits 4973 (-10) et 5700 (-1) ; stocks originaux conservés Retenir l’isolement avec validation métier ; aucune correction automatique Le contrôle ne permet pas de déterminer la quantité correcte de stock
IA-09 3.2 — Gestion des anomalies Tester une gestion adaptée des lignes Web sans SKU en distinguant celles qui contiennent des informations utiles ChatGPT À partir des 85 lignes Web sans SKU détectées en 3.1, propose un test permettant de distinguer les lignes contenant des informations produit utiles de celles qui n’en contiennent pas selon la règle testée. Ne considère pas automatiquement les valeurs techniques par défaut comme 0 comme des informations utiles. Ne supprime aucune ligne et ne modifie pas web_poc. Vérifie que toutes les lignes sont classées et que la source reste inchangée. Créer une copie de web_poc, identifier les SKU manquants, distinguer les lignes selon la présence d’informations utiles, puis attribuer une décision de gestion différente sans supprimer les données Exécution dans Colab, lecture des 2 lignes contenant des informations utiles et vérification d’exemples parmi les 83 autres 85 lignes sans SKU identifiées, dont 2 avec informations produit utiles et 83 sans information utile identifiée selon la règle testée. Toutes les lignes ont été classées et web_poc est resté inchangé. Conserver les 2 lignes pour validation métier ; isoler les 83 autres comme candidates à exclusion ; aucune suppression automatique La notion d’ information utile dépend de la règle testée. Les 83 lignes ne peuvent donc pas être considérées comme définitivement inutiles sans validation métier
IA-10 3.2 — Gestion des anomalies Comprendre la nature des SKU dupliqués avant de décider s’ils peuvent être supprimés ChatGPT À partir des SKU dupliqués détectés dans web_poc, propose un test permettant de distinguer les lignes totalement identiques des lignes ayant le même SKU mais des informations différentes. Exclure les SKU manquants déjà étudiés séparément. Ne supprimer ni modifier aucune ligne et vérifier que web_poc reste inchangé. Regrouper les lignes par SKU renseigné, comparer les lignes de chaque groupe, classer les groupes en « lignes totalement identiques » ou « même SKU avec informations différentes », puis afficher un résumé Exécution dans Colab, lecture du résumé et vérification d’exemples de SKU dupliqués 1 428 lignes pour 714 SKU distincts ; chaque SKU apparaît deux fois ; les 714 groupes contiennent des informations différentes ; web_poc reste inchangé Ne pas supprimer automatiquement les lignes dupliquées sur SKU ; conserver les données pour mesurer leur impact lors des jointures Le test montre que les lignes diffèrent, mais ne permet pas encore de déterminer si cette répétition est normale ou problématique pour la cardinalité
IA-11 3.2 — Gestion des anomalies Tester une gestion sûre des id_web manquants. ChatGPT À partir des 91 id_web manquants détectés dans liaison_poc, propose un test permettant d’identifier et d’isoler ces lignes sans inventer d’identifiant. Vérifie que les 91 lignes sont retrouvées, qu’aucun id_web n’est modifié et que liaison_poc reste inchangé. Créer une copie de liaison_poc, détecter les id_web manquants, créer une table dédiée avec la décision « validation requise », puis vérifier que les données originales restent intactes. Exécution dans Colab et contrôle du nombre de lignes isolées et de la conservation des données 91 lignes isolées ; id_web originaux conservés ; liaison_poc inchangé. Retenir l’isolement et la validation métier sans création automatique d’identifiant. Le test ne permet pas de retrouver la valeur correcte de id_web.
IA-12 3.3 — Sécurisation des jointures et de la cardinalité Vérifier que la jointure ERP ↔ Liaison respecte une cardinalité 1:1 et ne crée pas de lignes supplémentaires ChatGPT À partir de erp_poc et liaison_poc, crée un test sécurisé de la jointure sur product_id. La cardinalité attendue est 1:1 car product_id est unique dans les deux sources. Utilise un contrôle de cardinalité, compare le nombre de lignes avant/après et compte les lignes appariées, ERP seulement et Liaison seulement. Vérifie aussi qu’aucune multiplication inattendue des lignes n’est créée. Ne modifie pas les sources. Utiliser pd.merge() avec validate="one_to_one" et indicator=True, calculer le nombre de lignes attendu et contrôler les catégories both, left_only et right_only Exécution dans Colab et contrôle des résultats avant/après fusion ERP : 825 lignes ; Liaison : 825 lignes ; cardinalité 1:1 respectée ; 825 lignes après fusion ; 825 appariées ; 0 left_only ; 0 right_only Retenir la jointure ERP ↔ Liaison avec contrôle explicite one_to_one et suivi des correspondances Ce test valide uniquement ERP ↔ Liaison ; il ne permet pas de conclure sur la jointure avec Web
IA-13 3.3 — Diagnostic jointure Liaison ↔ Web Comprendre pourquoi la jointure du P6 multiplie fortement le nombre de lignes ChatGPT À partir de liaison_poc et web_poc, reproduis la jointure Liaison ↔ Web comme dans le P6 et mesure l’effet des clés manquantes. Compte les lignes avant/après, les catégories both, left_only, right_only, puis vérifie combien d’appariements proviennent de id_web et sku tous deux manquants. Reproduire la fusion brute avec indicator=True, puis filtrer les lignes où id_web et sku sont tous deux manquants pour mesurer les faux appariements Exécution dans Colab et comparaison des comptes 9183 lignes après fusion ; 9163 both ; 20 left_only ; 0 right_only ; 7735 appariements sur clés manquantes, soit exactement 91 × 85 Ne pas conserver cette stratégie de jointure brute ; construire une jointure sécurisée excluant les clés manquantes de l’appariement Ce diagnostic explique la multiplication liée aux clés manquantes, mais pas encore la gestion finale des 20 non-correspondances ni l’impact exact des SKU répétés
IA-14 3.3 — Sécurisation des jointures et de la cardinalité Tester une jointure Liaison ↔ Web qui évite les appariements artificiels sur clés manquantes ChatGPT À partir du diagnostic 2A, propose une jointure sécurisée entre liaison_poc et web_poc. Exclure les id_web et sku manquants de l’appariement, conserver ces lignes séparément, imposer une cardinalité 1:N sur les clés renseignées, puis compter both, left_only, right_only et vérifier qu’aucun appariement artificiel sur clés manquantes n’est créé. Ne modifie pas les sources. Séparer les clés renseignées des clés manquantes, joindre uniquement les clés renseignées avec validate="one_to_many" et indicator=True, puis contrôler les correspondances et conserver les lignes à clé manquante à part Exécution dans Colab et comparaison directe avec le Test 2A Cardinalité 1:N respectée ; 1 448 lignes après jointure ; 1 428 both ; 20 left_only ; 0 right_only ; 0 appariement artificiel ; 91 id_web manquants et 85 sku manquants conservés séparément Retenir la jointure sécurisée sur les clés renseignées uniquement, avec contrôle one_to_many La stratégie sécurise les clés manquantes mais n’explique pas encore la cause des 20 left_only
IA-15 3.3 — Analyse des non-correspondances Comprendre pourquoi 20 lignes Liaison avec un id_web renseigné restent sans correspondance dans Web ChatGPT À partir des 20 lignes left_only obtenues après la jointure sécurisée Liaison ↔ Web, vérifie que leurs id_web sont réellement absents de Web puis enrichis ces lignes avec les informations ERP, notamment onsale_web, stock_quantity et stock_status, afin d’identifier une éventuelle caractéristique commune. Ne modifie aucune donnée. Isoler les left_only, vérifier leurs identifiants dans Web puis les rapprocher de erp_poc sur product_id pour analyser leur profil Exécution dans Colab et lecture des 20 lignes ainsi que de la répartition de onsale_web 20 lignes, 20 id_web distincts, 0 identifiant retrouvé dans Web ; les 20 produits ont onsale_web = 0 Considérer ces 20 cas comme des non-correspondances expliquées ; ne pas créer artificiellement de correspondance Web Notebook POC — 3.3 — Test 3 Analyse des 20 non-correspondances
IA-16 4.1 Intégration des règles de gestion dans le P6 amélioré. egrouper les règles validées de 3.2 dans un bloc opérationnel unique ChatGPT À partir des règles validées pendant le POC 3.2, construis un bloc final et compact pour intégrer la gestion des anomalies dans la copie améliorée du P6. Travaille à partir de erp_poc, web_poc et liaison_poc sans les modifier. Crée des copies de travail. Intègre la règle générale stock/statut validée ; isole les prix et stocks négatifs sans les corriger ; distingue les lignes Web sans SKU avec informations utiles des autres ; conserve les SKU dupliqués sans déduplication automatique ; isole les id_web manquants. Le bloc doit produire un résumé lisible permettant de comparer les résultats avec ceux du POC. Créer erp_ameliore, web_ameliore et liaison_ameliore, appliquer uniquement la règle stock/statut autorisée, produire des tables séparées pour les autres anomalies et afficher un résumé des volumes obtenus Exécution dans Colab ; comparaison des 7 résultats obtenus avec ceux du POC 3.2 ; contrôle complémentaire du nombre d’incohérences stock/statut après intégration Les résultats reproduisent ceux du POC : 2 corrections stock/statut, 3 prix négatifs, 2 stocks négatifs, 2 lignes sans SKU avec informations utiles, 83 sans information utile identifiée, 1 428 lignes avec SKU dupliqué renseigné et 91 id_web manquants. Vérification finale : 0 incohérence stock/statut restante Retenir le bloc 4.1 dans la version améliorée du P6 Seule la cohérence stock/statut est corrigée automatiquement. Les anomalies sans valeur métier connue restent isolées ou soumises à validation humaine
IA-17 4.2 — Intégrer la sécurisation des jointures dans une copie du P6 Intégrer dans le P6 amélioré les stratégies de jointure validées en 3.3 ChatGPT À partir des stratégies validées en 3.3 et des DataFrames erp_ameliore, liaison_ameliore et web_ameliore, construis un bloc final de jointures sécurisées pour le P6 amélioré. La jointure ERP ↔ Liaison doit imposer une cardinalité 1:1. Pour Liaison ↔ Web, exclure les clés id_web et sku manquantes de l’appariement, conserver ces lignes séparément, imposer une cardinalité 1:N, identifier both, left_only et right_only, vérifier l’absence d’appariements artificiels et confirmer que les sources de travail ne sont pas modifiées. Créer deux jointures contrôlées avec validate="one_to_one" puis validate="one_to_many", séparer les clés manquantes avant la fusion Web et produire des contrôles de sécurité et de correspondance Exécution dans Colab et comparaison avec les résultats du POC 3.3 ERP↔Liaison : 825 appariées, 0 non appariée. Liaison↔Web : 1 428 appariées, 20 left_only, 0 right_only. 91 id_web et 85 sku manquants séparés. 0 faux appariement. 20 exceptions onsale_web=0. Sources inchangées Retenir le bloc 4.2 dans le P6 amélioré Les clés absentes ne sont pas complétées automatiquement et les exceptions restent conservées séparément
IA-18 4.3 — Centraliser les contrôles et enregistrer les résultats d’exécution Automatiser la centralisation des résultats produits par 4.1 et 4.2. ChatGPT À partir des résultats déjà produits par les blocs 4.1 et 4.2 du P6 amélioré, construis un journal automatique unique reprenant le format défini en 2.1 : Run ID, date, source/périmètre, contrôle, règle attendue, résultat, détail anomalie, action/décision, validation humaine et preuve. Le journal doit récupérer les résultats existants sans refaire les analyses et être exportable en CSV. Générer un Run ID horodaté, récupérer les variables produites par 4.1 et 4.2, construire un DataFrame unique de contrôles et l’exporter en CSV. Réexécution de 4.1 puis 4.2 et 4.3 dans une même session Colab ; vérification du DataFrame généré. Journal automatique généré avec 8 contrôles et un Run ID unique. Retenir cette centralisation automatique dans le P6 amélioré. Le journal dépend de l’exécution préalable des blocs 4.1 et 4.2 dans la session ; après expiration du runtime, les cellules doivent être réexécutées dans l’ordre.
IA-19 5.1 — Exécuter les tests de validation sur les jointures et anomalies Vérifier automatiquement que l’intégration du P6 amélioré n’a pas réintroduit les problèmes corrigés ou sécurisés pendant le POC ChatGPT À partir des résultats intégrés dans les LOT 4.1, 4.2 et 4.3, construis un bloc unique et court de tests de non-régression. Il doit vérifier les résultats critiques suivants : 0 incohérence stock/statut, 3 prix négatifs isolés, 2 stocks négatifs isolés, 0 ligne non appariée ERP ↔ Liaison, 0 faux appariement sur clés manquantes, 20 exceptions Web expliquées par onsale_web = 0 et présence d’un journal automatique de 8 contrôles. Le code ne doit modifier aucune donnée et doit produire un tableau de résultats ainsi qu’un verdict global. Créer un DataFrame de 7 tests comparant valeur attendue et valeur obtenue, puis produire automatiquement un statut OK/ÉCHEC et un verdict global Exécution dans Colab et lecture du tableau des 7 contrôles 7 tests sur 7 validés ; aucune régression détectée Valider la version intégrée du P6 amélioré pour poursuivre la comparaison avant/après Les tests couvrent uniquement le périmètre amélioré du projet et ne constituent pas une couverture exhaustive de tout le notebook P6
IA-20 5.2 — Vérifier la reproductibilité et la traçabilité Vérifier que deux exécutions successives du P6 amélioré produisent les mêmes résultats métier tout en restant identifiables séparément ChatGPT À partir du journal automatique généré en 4.3, propose un test simple de reproductibilité entre deux exécutions successives du P6 amélioré sur les mêmes données. Le test doit sauvegarder le Run 1, comparer ses résultats au Run 2 en excluant le Run ID et la date, vérifier que les deux runs contiennent le même nombre de contrôles, que les résultats métier sont identiques et que les Run ID sont différents. Produire un tableau comparatif et un verdict global. Sauvegarder deux DataFrames de journal, comparer uniquement les colonnes métier après tri et vérifier séparément l’unicité des Run ID Réexécution de 4.1 → 4.2 → 4.3 puis comparaison des deux journaux dans Colab Run 1 et Run 2 contiennent chacun 8 contrôles, les résultats métier sont identiques et les Run ID sont distincts Valider la reproductibilité et la traçabilité du P6 amélioré sur les données testées Le test porte sur deux exécutions utilisant les mêmes données et le même environnement Colab
IA-21 5.3 — Comparer le P6 initial et le P6 amélioré Construire une synthèse objective des gains du P6 amélioré uniquement à partir des résultats réellement obtenus pendant le projet ChatGPT À partir des preuves obtenues dans l’audit du P6 initial, le POC et les LOT 4 et 5, construis un tableau comparatif final P6 initial ↔ P6 amélioré. Comparer uniquement les éléments effectivement testés : cohérence stock/statut, prix négatifs, stocks négatifs, jointure ERP ↔ Liaison, jointure Liaison ↔ Web, non-correspondances Web, traçabilité, reproductibilité et validation après intégration. Pour chaque dimension, indiquer le P6 initial, le P6 amélioré, la preuve obtenue, le gain et la limite. Ne pas inventer de métrique ou de bénéfice non mesuré. Construire un tableau à 6 colonnes : Dimension ; P6 initial ; P6 amélioré ; Preuve obtenue ; Gain ; Limite Comparaison du tableau avec les résultats réellement exécutés dans le notebook et les journaux du projet Tableau comparatif final produit sur 9 dimensions, avec notamment 2 → 0 incohérences stock/statut, 7 735 → 0 faux appariements, 20/20 exceptions expliquées, 8 contrôles reproductibles et 7/7 tests de non-régression validés Retenir la version améliorée sur le périmètre testé et utiliser ce comparatif comme preuve finale du gain du projet La comparaison porte uniquement sur le périmètre amélioré ; certains gains sont qualitatifs et certaines anomalies restent soumises à validation métier