Ce qu'il faut demander à vos diagnostiqueurs
À quoi ça sert
Vos diagnostics sont traités automatiquement à leur arrivée dans la GED Stonal Smartdoc : ils y sont classés, et les informations qu'ils contiennent en sont extraites.
La qualité de ce traitement dépend beaucoup de la façon dont les documents ont été produits. Les recommandations ci-dessous sont donc à faire passer à vos prestataires diagnostiqueurs, idéalement en les inscrivant dans le cahier des charges de vos marchés.
Un diagnostic qui ne les respecte pas sera bien pris en charge. Ces recommandations visent à simplifier fortement la transmission de vos diagnostics et à augmenter l'exploitabilité des informations qu'ils contiennent.
1. Transmettre les diagnostics via API
C'est la recommandation qui apporte le plus. Demandez à vos diagnostiqueurs d'utiliser notre API documentaire pour déposer automatiquement leurs diagnostics.
Vous y gagnez :
- une intégration directe et immédiate, sans transmission manuelle — donc sans oubli, sans erreur de destinataire et sans délai ;
- des analyses de conformité constamment à jour, puisque le diagnostic arrive dès qu'il est produit.
L'API est disponible et documentée : Déposer un fichier.
2. Utiliser la codification bâtimentaire Stonal
Demandez à vos diagnostiqueurs de reprendre les codes de votre patrimoine tels qu'ils existent dans Stonal pour désigner ce qu'ils diagnostiquent : bâtiments, lots, locaux.
Sans cela, il faut deviner à quoi rattacher chaque document. Avec, le rattachement est certain.
Vos diagnostiqueurs peuvent interroger directement notre base pour récupérer ces codes, sans vous solliciter : voir Rechercher des données dans le Guide API.
3. Faire transmettre les métadonnées
Notre intelligence artificielle extrait automatiquement les informations clés d'un diagnostic — date de visite, validité, étiquette, résultat. Mais un document de mauvaise qualité ou dans un format inadapté limite la précision de cette extraction.
Quand c'est possible, faites transmettre ces informations directement par API. Le taux d'erreur devient alors nul, puisqu'il n'y a plus rien à interpréter.
4. Quand l'API n'est pas possible : produire des documents lisibles
Ces bonnes pratiques augmentent nettement la précision des extractions :
| Bonne pratique | Pourquoi |
|---|---|
| Des PDF natifs, pas des scans | Évite les erreurs de reconnaissance de caractères |
| Un diagnostic par fichier, sans page de garde | Un PDF qui agrège plusieurs diagnostics est difficile à découper |
| Si un scan est inévitable, une numérisation de qualité | Bonne résolution, page droite, contraste correct, sans rotation ; éviter le texte en couleur |
| Des mentions explicites en texte brut pour les informations clés | Une information lisible est une information extractible |
| Pas de cases à cocher, ni de mentions présentes seulement dans une image ou un filigrane | Ces éléments ne sont pas du texte, même dans un PDF natif |
| Une structure de document homogène entre prestataires | Réduit les erreurs et simplifie le traitement |
| Le code de la résidence et du lot dans le nom et dans le contenu du document | C'est ce qui permet de rattacher le document au bon endroit |
Notre intelligence artificielle les traite bien. En revanche, pour les informations qui n'existent que dans un schéma technique ou sur un plan — une localisation, par exemple — une description écrite reste nettement plus fiable.
Voir aussi
- Les documents d'une résidence — ce que devient un diagnostic une fois déposé
- Le rapport Conformité — ce que ces diagnostics alimentent
- Guide API — Déposer un fichier