Le camion est revenu. Le planning marque l'intervention terminée. Le client demande son justificatif, tandis que la facturation attend encore une quantité confirmée. Dans Trackdéchets, le bordereau a avancé, mais votre logiciel d'exploitation conserve un statut devenu trop vague pour expliquer la situation.
Une intégration Trackdéchets utile relie la prestation commerciale, le mouvement physique et le cycle du bordereau sans les confondre. Pour une entreprise de collecte, un exploitant ou un producteur de déchets en France, cette distinction détermine ce que les équipes peuvent automatiser et ce qui doit rester soumis à une vérification.
Commencer par le dossier d'exploitation
La documentation officielle présente une API GraphQL permettant aux logiciels métier de communiquer avec la plateforme. Cette connexion constitue une possibilité technique. Elle ne définit pas à elle seule votre organisation interne ni la façon dont une prestation devient facturable.
Prenons un scénario de conception : une intervention prévue concerne un site client et un flux de déchets identifié. Une collecte est réalisée, puis la destination enregistre sa réception. Des informations complémentaires ou une différence de poids demandent une action. Le dossier commercial doit conserver le lien entre ces événements, même s'ils sont enregistrés par des personnes différentes dans plusieurs outils.
Avant de demander un devis, dessinez ce dossier sur une page. Identifiez la référence de prestation, le site, les établissements concernés, le bordereau et les justificatifs. Précisez qui possède chaque donnée. Un nom d'entreprise similaire ou une date de passage ne suffisent pas pour rattacher automatiquement des documents au bon client.
Ne pas transformer tous les états en « terminé »
La référence des statuts BSDD distingue notamment le transit, la réception, l'acceptation et le traitement. Elle prévoit aussi d'autres situations, comme le refus et l'entreposage temporaire. Une interface qui réduit ces étapes à un seul voyant vert retire aux équipes des informations nécessaires.
Dans votre application, séparez l'état de la prestation, l'état du transport et l'état observé du bordereau. Présentez un résumé adapté au métier, mais permettez d'en comprendre l'origine. Une personne du support doit pouvoir répondre à la question « qu'attend-on maintenant ? » sans interpréter une liste de codes techniques.
Les transitions autorisées dépendent du type de bordereau et du rôle de l'acteur. Demandez au prestataire de vérifier le parcours réellement utilisé, plutôt que d'appliquer les règles d'un BSDD à tous les flux. Une première version limitée à un type de bordereau correctement traité est préférable à une promesse de couverture générale impossible à démontrer.
Donner une origine à chaque quantité
Une quantité prévue, une quantité mesurée et une quantité acceptée ne racontent pas nécessairement la même chose. Le logiciel doit conserver leur nature, leur unité et leur provenance. Une valeur actualisée ne doit pas effacer silencieusement celle qui a servi à préparer le transport ou à informer le client.
Rattachez les pièces justificatives au bon événement. Si une pesée est enregistrée dans un outil distinct, définissez comment son identifiant rejoint la collecte et le bordereau. Le rapprochement peut être automatique lorsque les références sont fiables. Dans les autres cas, prévoyez une proposition à valider et une file des dossiers non rapprochés.
Évitez de déclencher automatiquement la facturation sur la seule arrivée d'un nouveau statut. Les conditions commerciales peuvent exiger une information complémentaire ou une validation interne. Formalisez le passage « exploitable pour la facturation » avec les responsables concernés et indiquez clairement les exceptions qui le bloquent.
Synchroniser les changements sans saturer l'API
Une bonne intégration ne relit pas sans cesse tous les bordereaux. Les bonnes pratiques officielles de consommation de l'API décrivent notamment l'utilisation des mises à jour depuis un instant donné et des informations de cycle de vie. Le prestataire doit choisir une stratégie compatible avec votre volume et les mécanismes documentés pour le flux concerné.
Le cahier des charges doit également couvrir la reprise. Si le connecteur s'arrête, comment retrouve-t-il les changements intervenus pendant l'interruption ? Comment évite-t-il de créer deux tâches internes après avoir relu le même événement ? Comment repère-t-il un dossier local qui ne correspond plus à l'état de la plateforme ?
Demandez un écran de suivi simple : dernier échange réussi, dossiers à reprendre, cause de l'erreur et action possible. Le message « synchronisation en erreur » ne suffit pas à une équipe qui doit organiser la journée suivante. L'exploitation doit distinguer une panne de connexion d'une donnée refusée ou d'une action réservée à un autre acteur.
Préserver les responsabilités des utilisateurs
Une automatisation doit respecter les droits des établissements et des personnes. Cartographiez les actions de consultation, préparation, validation et signature prévues dans votre parcours. Évitez qu'un compte technique trop large transforme une simple mise à jour d'exploitation en action engageante non prévue.
Séparez les environnements de test et de production. Les démonstrations doivent employer des données de test adaptées, avec des secrets distincts. Les journaux techniques doivent aider à résoudre les erreurs sans devenir une copie supplémentaire de tous les dossiers clients.
La conservation des preuves mérite une décision explicite. Déterminez avec les responsables compétents quelles pièces garder, pour quel usage et avec quelles restrictions d'accès. Une sauvegarde technique ne remplace pas une politique documentaire, et un lien vers une pièce externe ne garantit pas sa disponibilité future.
Acheter un parcours complet et vérifiable
Pour un premier projet, retenez un établissement, un type de bordereau et une prestation récurrente. Le périmètre peut couvrir la préparation, l'association des références, le suivi de réception et une transmission contrôlée vers la facturation. Il doit inclure les cas qui perturbent aujourd'hui vos équipes.
- ▸Une donnée obligatoire manque au moment de préparer le dossier.
- ▸Le même événement est reçu plusieurs fois.
- ▸La réception apporte une quantité différente de celle attendue.
- ▸Un refus impose une nouvelle décision d'exploitation.
- ▸La plateforme est indisponible pendant une partie du parcours.
- ▸Le connecteur reprend alors que des dossiers ont évolué ailleurs.
Pour chaque situation, demandez au fournisseur de montrer l'action attendue, son responsable et la preuve conservée. Mesurez ensuite les dossiers incomplets, les doubles saisies restantes et les rapprochements manuels. Ces observations permettent de décider si une extension à d'autres flux est justifiée.
Préparer une demande de développement utile
Un connecteur standard peut suffire lorsque votre logiciel et vos parcours sont déjà couverts. Le sur mesure devient pertinent lorsque plusieurs outils doivent partager un dossier opérationnel ou lorsque les exceptions restent gérées par e-mail malgré la connexion existante. Comparez ces deux options sur un même exemple réel anonymisé.
Notre guide du cadrage et de la recette d'un logiciel métier aide à traduire ce parcours en livrables. Le sujet des applications terrain et des sites d'intervention complète la réflexion lorsque la collecte dépend d'informations d'accès précises.
TuniCyberLabs accompagne le développement de logiciels métier et d'intégrations. Pour étudier votre connexion Trackdéchets, présentez vos outils actuels, le type de bordereau concerné et un dossier qui nécessite encore une reprise manuelle. Le premier objectif sera de rendre ce dossier cohérent de bout en bout.