Aller au contenu

Problématiques identifiées sur la convergence

À quoi sert ce document. Recenser tous les problèmes constatés sur la convergence, avec ce qu'on sait de leur cause et l'état du travail déjà entamé. Les tickets correspondants sont mis en attente : ce document permet de décider lesquels reprendre, sans avoir à les lire un par un.

Comment le lire. Chaque entrée dit le problème, ce qu'on en sait, et où en était le travail. Aucun prérequis de contexte. Les liens mènent au détail technique quand il existe.

Rappel de ce qu'est la convergence. Plusieurs méthodes automatiques lisent le même dossier, chacune à sa façon. Quand elles trouvent la même valeur, la donnée est considérée fiable et personne ne rouvre le document. Quand elles divergent, le conflit est signalé. Les méthodes sont appelées source A, B, C et D devant les équipes.

Note de correspondance (pour les tech, hors présentation AM). L'anonymisation A/B/C/D a été décidée le 22/07 pour éviter que les AM privilégient une colonne par habitude — elle est maintenue côté équipes AM. Deux identités ont toutefois été nommées ouvertement en atelier le 14/08 et sont donc reprises ici : source A = Manus, source D = Composable. Le mapping complet des quatre sources n'est volontairement pas publié ici (il lève l'anonymisation en entier). Source : atelier convergence 14/08.

1. La convergence peut retenir une valeur fausse

Le problème. Si deux méthodes sur trois se trompent de la même façon, la convergence retient leur valeur et l'affiche comme vraie. Le nombre de méthodes d'accord fait foi, indépendamment de ce que disent les documents.

Ce qu'on sait. C'est le comportement actuel, et il est jugé non souhaitable. Un accord entre méthodes n'est pas une preuve : sur un dossier audité, deux méthodes annonçaient le même budget de travaux et citaient toutes deux un passage indiquant un montant différent.

Direction retenue (14/08). La convergence doit pouvoir consulter les documents elle-même, et non se contenter des résultats des méthodes. Cela suppose de stocker chaque document avec sa pagination et un résumé structuré, pour qu'elle tranche sur le contexte du dossier plutôt que sur un passage isolé. Piste complémentaire : faire tourner l'arbitre sur un modèle d'IA différent de celui des méthodes, sinon les résultats s'uniformisent.

Travail entamé. BRI-1689 — arbitrage fondé sur une preuve documentaire (Todo, Dimitri). C'est la même direction.

2. La citation ne correspond pas toujours à la valeur affichée

Le problème. Chaque méthode affiche une valeur et cite un passage de document censé la justifier. Souvent, le passage ne dit pas ce que la valeur affirme. Exemple réel : un prix d'acquisition de 600 000 € justifié par un passage indiquant six cent vingt-cinq mille euros. Autre exemple : un prix justifié par la durée de vie de la société, tirée d'un extrait d'immatriculation.

Ce qu'on sait. Mesuré sur 88 citations de 12 dossiers réels : 64 % des citations tiennent pour la source B, 74 % pour la source D. Cause probable identifiée par Dimitri : la citation remontée serait la première de la liste, alors que la valeur affichée est celle retenue par l'arbitre — un défaut d'appariement, à localiser côté Python ou côté application.

Niveau de confiance : ces 88 jugements ont été portés par un seul lecteur (Jérôme, 13/08), sans révision par un second relecteur. Les taux 64 % / 74 % sont donc indicatifs, pas des mesures consolidées.

Décision (14/08). La cohérence entre citation et valeur est la responsabilité de chaque méthode, pas de l'application. Une méthode ne doit pas pouvoir remonter une valeur si le passage cité ne la contient pas.

Détail : BRI-1932 (audit complet, terminé). Livrables : contexte, couverture par source, constat d'instrumentation.

3. On ne peut pas remonter d'une valeur à la phrase qui la justifie

Le problème. Il n'existe pas, dans la base, d'endroit qui réunisse à la fois le texte exact cité, le document d'où il vient et la page. Le champ prévu pour la phrase exacte n'est rempli nulle part — sur 160 919 entrées (mesuré le 13/08/2026, relevé base prod non revérifié) — alors que l'interface le lit en priorité et retombe silencieusement sur un champ de secours. Et le document n'est identifié que par son nom : le lien vers le fichier est reconstitué à l'affichage par ressemblance de nom.

Pourquoi ça compte. Sans cela, impossible de vérifier automatiquement la qualité des citations, ni de garantir la traçabilité exigée côté réglementaire.

Travail entamé. BRI-1978 — rendre une citation vérifiable de bout en bout (Backlog). Le bon moment pour poser ce contrat est avant la refonte, pas après.

4. Les adresses sont mal consolidées

Le problème. L'adresse retenue est parfois réduite à la commune, ce qui rend le géocodage imprécis et fait remonter une parcelle cadastrale fausse. À l'inverse, quand deux méthodes donnent la même adresse écrite différemment, le système déclenche une intervention humaine inutile.

Ce qu'on sait. Le cas a été remonté par le comité (retour de Cédric sur un mémo). La règle voulue : reconnaître que deux adresses désignent le même lieu, retenir la plus complète, et ne pas solliciter un humain pour une simple différence de mise en forme.

Piste évoquée le 14/08. Croiser une API de cartographie et le cadastre pour normaliser l'adresse, avec intervention humaine seulement en cas de doute réel. Les données de performance énergétique peuvent aussi servir de recoupement. Jugé trop tôt pour être traité en séance.

Travail entamé. BRI-1690 — règle adresse (In Review) et BRI-1833 — adresse réduite à la commune (Backlog). Même sujet, deux tickets.

5. Ce que déclare le porteur est traité comme une source à part entière

Le problème. Ce que le porteur affirme sans preuve — un message, un document qu'il a rédigé lui-même — apparaît aujourd'hui comme une colonne parmi les autres sources. Un coût de travaux tapé dans un document Word n'a pourtant pas la même valeur qu'une somme de devis aboutissant au même montant.

Décision (14/08). Le déclaratif ne doit plus être une colonne. Il devient une annotation qui signale que la donnée n'est pas exploitable en l'état, et qui déclenche la demande d'un document officiel. Il entre dans le résumé du projet avec la mention explicite qu'il doit être vérifié. Pour les traitements où on n'en veut aucun, la section déclarative n'est pas fournie à l'IA.

Besoin identifié en séance. Un champ estimé par l'IA indiquant si un document est authentique ou déclaratif, permettant de filtrer. Le filtre actuel repose sur le nom du fichier : si le porteur nomme son document autrement, il passe pour officiel.

Travail entamé. BRI-1931 — qualifier chaque document officiel ou déclaratif (Backlog, Dimitri). BRI-1713 — cas réel d'une valeur extraite à 0 alors que le document cité indique 18 000 (Backlog).

6. Les deux canaux du déclaratif sont confondus

Le problème. Les messages du CRM et la fiche remplie par le porteur arrivent fusionnés sous une seule étiquette. Une donnée venant de la messagerie s'affiche donc comme venant de la fiche, avec un niveau de confiance qui n'est pas le bon.

Tension à connaître. Romain considère que ces deux canaux sont métier la même chose — dans les deux cas c'est le porteur qui parle sans preuve. Le ticket existant demande au contraire de les séparer techniquement. Les deux sont défendables ; et si le déclaratif cesse d'être une colonne (point 5), la séparation perd son intérêt.

Écart avec le wiki à connaître : ADR-013 traite crm_messagerie (rang 3) et declarative_bubble (rang 4) comme deux sources distinctes, départagées par leur fraîcheur. La position du 14/08 (une seule source déclarative) n'a pas été reportée dans l'ADR — non tranché ici, à arbitrer avant de modifier l'ordre de précédence.

Travail entamé. BRI-1643 (Todo). Simplification volontaire au départ, pas un accident.

7. Deux mécanismes différents portent le même nom

Le problème. Le mot « précédence » désigne deux choses distinctes, ce qui a créé de la confusion en séance. D'un côté, l'ordre entre les sources techniques : quelle colonne l'emporte quand l'arbitre ne tranche pas. De l'autre, le respect de la décision humaine : une valeur validée par une personne ne doit jamais être écrasée par une nouvelle analyse.

Ce qu'on sait. Le second mécanisme avait disparu et Romain l'a rétabli : en cas d'écart entre ce qu'un humain a validé et ce qu'une nouvelle analyse trouve, un panneau signale le conflit et propose de changer la valeur — sans jamais la remplacer automatiquement. Le principe : l'humain dispose d'un contexte que la machine n'a pas, et le travail de fiabilisation d'un account manager ne doit pas être effacé sans concertation.

Point ouvert. Il existe deux canaux techniques non unifiés pour enregistrer une décision humaine. Tant qu'ils coexistent, les garde-fous peuvent différer selon le chemin emprunté.

Travail entamé. BRI-1687 — ordre des sources pilotable (In Review) et BRI-1639 — unifier les deux canaux de décision humaine (Todo).

8. Une méthode ne justifie jamais ce qu'elle affirme

Le problème. La source A propose une valeur dans 7 dossiers sur 10 (71,5 %, mesuré le 13/08/2026 sur 499 dossiers, relevé base prod non revérifié), et n'a jamais fourni une seule justification consultable en six mois. C'est même la méthode qui se prononce le plus souvent sur l'adresse et le prix d'acquisition. Quand elle tombe d'accord avec une autre, cet accord est traité comme un signe de fiabilité, alors qu'aucune des deux ne peut montrer d'où vient sa valeur.

Décision (14/08). Ce n'est pas un défaut à corriger : des tests passés ont montré que forcer cette méthode à citer la conduisait à inventer des citations. Elle est donc déclassée — dernier recours quand les autres n'ont rien trouvé, ou challenger. Elle n'a pas vocation à être la source de vérité, faute de traçabilité.

9. Ce qui n'est pas testé automatiquement

Le problème. Il n'y a pas de tests automatisés sur les modifications du dépôt qui porte la convergence, et les tests existants ne protègent pas contre une variable de configuration mal renseignée. Un incident de ce type s'est produit : les variables d'environnement d'un environnement de test ont été effacées, rendant ses données non représentatives pendant des semaines.

Travail entamé. BRI-1640 — ajouter des tests automatiques sur les modifications et durcir les tests existants (Todo). C'est le moment de le faire, avant la refonte.

10. Un point d'entrée insuffisamment protégé

Le problème. Le point d'entrée par lequel la convergence est déclenchée accepte des chemins trop largement. Un appel malveillant pourrait s'en servir pour faire agir le système à sa place.

Travail entamé. BRI-933 — restreindre les chemins acceptés (Backlog). Seul sujet de sécurité de la liste — à ne pas perdre dans un archivage.

11. Ce qui ne sert plus mais fonctionne encore

Le problème. Un ancien canal de validation, officiellement remplacé, est toujours en service. Tant qu'il existe, une décision peut passer par lui et échapper aux règles définies pour le canal actuel.

Travail entamé. BRI-1637 — mettre hors service l'ancien canal (Todo).

12. Les types de biens ne sont pas nommés pareil de part et d'autre

Le problème. Le traitement automatique renvoie les types de biens en français alors que le reste du système les attend en anglais. Les valeurs ne se raccordent donc pas toujours.

Travail entamé. BRI-708 (Backlog). Petit sujet, cause réelle d'incohérences.

13. La configuration de mise en service n'est pas documentée

Le problème. Les réglages qui déterminent quelle proportion des dossiers passe par la convergence, et si elle se déclenche automatiquement, ne sont pas documentés et ne correspondent pas forcément entre les environnements. Par ailleurs, l'interface ne sait pas dire si la convergence a tourné sur un dossier.

Travail entamé. BRI-1641 — réconcilier et documenter la configuration (Todo) et BRI-936 — exposer un signal « la convergence a tourné » (Todo).

14. Ce que l'account manager voit ne lui permet pas de trancher

Le problème. Quand des valeurs se contredisent, l'account manager doit changer d'écran, retrouver le document et chercher le passage lui-même. L'affichage actuel en colonnes par source ne permet pas de cliquer sur un conflit et d'ouvrir le document à la bonne page.

Ce qui est voulu. Voir les conflits, cliquer sur l'un d'eux, obtenir une explication et parcourir le document sans quitter l'écran. Décision du 14/08 : cela mérite un projet dédié, l'affichage actuel rendant la chose difficile.

Travail entamé. BRI-1177 — lisibilité et localisation dans le document (Backlog), BRI-1160 — rendre visible la validation de l'account manager (Backlog), BRI-1642 — cohérence de l'indicateur de fiabilité (Todo), BRI-1712 — champ affiché sans provenance (Todo).

15. Où vit la convergence, et comment on l'agrandit

Le problème. La convergence était packagée avec une partie des sources qu'elle consomme, ce qui la mettait en position de juge et partie.

Décision (14/08). Elle reste dans le dépôt Python, sur une route indépendante — c'est déjà le cas. Un service et un serveur séparés sont écartés pour raison de coût. Le choix de conserver plusieurs méthodes concurrentes est maintenu, malgré la complexité technique qu'il engendre : c'est ce qui permet de savoir si la méthode principale est bonne, faute de quoi on n'aurait aucun point de comparaison. Dimitri signalera au fil de l'eau les complications que ce choix produit, pour qu'on arbitre avec des faits.

Piste pour plus tard. Ouvrir un accès standardisé par projet permettrait de brancher une méthode alternative sans l'intégrer au dépôt.

Travail entamé. BRI-875 — extraction de la convergence (In Progress, avec trois demandes de fusion de code déjà ouvertes). Sa cible d'origine n'est plus d'actualité.

16. Deux points de vigilance techniques

Les calculs et les arrondis. Les calculs faits dans le langage de l'application ne sont pas fiables au niveau de la décimale. Pour toute donnée qui doit être précise, il faut passer par une bibliothèque mathématique dédiée. À prendre en compte pour les valeurs qui se déduisent d'autres valeurs, qu'on a décidé de calculer plutôt que de faire lire par une IA.

La charge. Stocker et traiter les documents entiers coûte en mémoire et en appels d'IA. Assumé au regard de l'enjeu, à optimiser plus tard.

Ce qui a déjà été réglé

À ne pas rouvrir. Ces sujets ont été traités et fermés.

  • Les sources externes n'étaient plus lues depuis un mois, à cause d'un point d'accès inexistant et d'un échec silencieux (BRI-1814).
  • L'arbitre tranchait contre une majorité de méthodes concordantes sans proposer d'intervention humaine (BRI-1675).
  • Les données saisies à la main par l'account manager étaient écrasées lors d'une nouvelle analyse (BRI-1227).
  • La justification de l'arbitre était illisible pour l'account manager (BRI-1688, BRI-1475).
  • Une colonne affichait une fiche republiée au lieu de l'extraction réelle (BRI-1674).

Sources de ce document