Retrouver l’historique d’un véhicule et les anomalies à examiner

Le besoin métier

Quand les informations d'un parc sont dispersées entre cartes grises, tableurs, factures de garage, relevés de carburant et messages, il devient difficile de répondre à une question pourtant simple : qu'est-ce qui s'est passé sur ce véhicule, combien cela a coûté et quelle échéance approche ? Deux immatriculations écrites différemment ou un ancien numéro de parc peuvent faire apparaître deux dossiers pour le même véhicule.

Les anomalies sont tout aussi importantes que les données régulières. Un kilométrage en recul peut être une erreur de saisie ou un changement de compteur ; un plein inhabituel peut venir d'un justificatif mal rapproché. Les corriger automatiquement ferait disparaître la possibilité d'enquêter. Le besoin était donc un registre unique qui facilite l'import et le rapprochement, mais qui conserve les sources et les incertitudes.

La solution et son périmètre

L'application web s'appuie sur une base SQLite. Chaque véhicule possède une fiche qui réunit ses identifiants, documents, interventions, dépenses, cartes carburant, relevés kilométriques et échéances. Les événements sont datés et rattachés à leurs pièces lorsque celles-ci existent. Une interface permet de consulter l'historique et de préparer des tableaux de suivi.

L'import assisté prend en charge des documents et données déjà présents dans l'organisation. Il recherche des correspondances par numéro de parc, immatriculation ou VIN selon ce que contient la source. Une empreinte de fichier aide à repérer les doublons. Les rapprochements incertains sont proposés à la validation, non imposés. Un jeu de données constructeur indicatif peut enrichir une fiche, mais il reste distinct des faits tirés des documents propres au véhicule.

Le parcours d'un document

1. Un fichier, une ligne de tableur ou un justificatif est présenté à l'application avec son origine.
2. Les champs disponibles sont extraits et rapprochés d'un véhicule connu au moyen des identifiants pertinents.
3. L'outil prépare un plan d'import : créations, mises à jour, doublons possibles et points à confirmer.
4. L'utilisateur contrôle ce plan avant de déclencher l'enregistrement.
5. Les changements sont appliqués dans une transaction, puis la source et les valeurs avant/après restent consultables.

Cette étape de préparation, parfois appelée simulation d'import, évite qu'un lot de documents mal interprétés modifie immédiatement l'ensemble du parc. Si le même lot revient, l'idempotence et la détection de doublons réduisent les répétitions. En cas d'échec pendant l'application, la transaction empêche qu'une partie du lot soit enregistrée comme si tout avait réussi.

Rapprocher sans effacer les anomalies

L'immatriculation est utile mais peut changer ; le numéro de parc peut être absent d'une facture ; le VIN est plus stable mais pas toujours lisible. Le rapprochement combine ces indices et doit afficher son niveau de certitude. Une correspondance ambiguë demande une décision humaine. Les documents rejetés ou en attente ne doivent pas disparaître : ils constituent la liste des points à résoudre.

Le suivi du carburant illustre cette règle. Une quantité invraisemblable reste visible dans l'enregistrement d'origine. Si un calcul de consommation exige une valeur bornée, cette valeur de calcul doit être clairement distinguée du justificatif et n'est utilisable qu'avec un kilométrage fiable. Sinon, le bon résultat est « non calculable » ou « à vérifier », pas un chiffre rassurant inventé par correction silencieuse.

Le plan d'import distingue une pièce nouvelle, une pièce déjà connue, une mise à jour et un document à arbitrer. Cette présentation réduit le temps consacré à ouvrir chaque fichier séparément. Elle concentre la revue humaine sur les exceptions : deux véhicules candidats, un VIN illisible ou une date incohérente. L'import est alors un travail contrôlé, pas une injection de données dont on découvre les effets après coup.

Historique, échéances et coûts

Une fiche véhicule devient utile lorsqu'elle raconte la succession des faits : acquisition et documents, entretien, réparation, contrôle, dépenses de carburant, kilométrages et échéances à venir. Les pièces permettent de revenir à une intervention donnée. Le tableau de bord peut alors signaler un contrôle proche, une succession de frais ou une incohérence de compteur.

Ces informations appuient des décisions de maintenance ou de remplacement, mais ne prennent pas cette décision. Un coût élevé sur une courte période peut justifier une revue ; il n'établit pas à lui seul qu'un véhicule doit sortir du parc. Il faut encore tenir compte de l'usage, de la disponibilité, des contrats et de l'état réel.

Pour la direction, une vue peut rapprocher les dépenses connues et l'utilisation d'un véhicule. Pour l'administration, la valeur se trouve souvent dans la recherche immédiate d'un justificatif ou d'une échéance. Pour les équipes terrain, une fiche à jour évite de répéter un signalement déjà documenté. Ces vues partagent le même historique, mais ne demandent pas nécessairement les mêmes droits d'accès.

Une interface pour les autres outils

Le projet décrit une API versionnée et protégée par des jetons à droits limités. Elle sert à consulter ou alimenter des données sans donner un accès général à la base. Les opérations d'import restent encadrées par le plan préalable et la trace des changements. Une intégration doit préciser qui peut créer, modifier ou seulement lire, et quelles pièces elle est autorisée à transmettre.

La journalisation avant/après aide à comprendre une correction : ancienne immatriculation, nouvelle valeur, source et moment de la modification. Elle ne transforme pas une donnée erronée en donnée juste ; elle rend l'erreur détectable et la correction explicable.

Une API destinée à d'autres outils doit aussi limiter son périmètre : un jeton de consultation n'a pas besoin de modifier une échéance, et un import automatisé ne devrait pas réécrire librement une fiche entière. Une version d'API et des réponses explicites sur les erreurs facilitent les intégrations sans cacher les cas de conflit. La base reste le référentiel, pas un simple réceptacle de fichiers.

Ce que l’IA apporte réellement

L'IA a contribué à concevoir le projet et peut assister l'extraction ou le classement de documents hétérogènes. Le cœur du registre repose toutefois sur des identifiants, des règles de rapprochement, des contrôles de doublons et des validations explicites. Une suggestion de correspondance n'est pas une preuve d'identité du véhicule.

La séparation entre aide et fait confirmé est particulièrement importante pour les données constructeur indicatives. Elles peuvent donner un repère, mais ne doivent pas écraser la carte grise, la facture, le relevé ou la mesure propre au véhicule. L'humain tranche les ambiguïtés et valide les corrections.

Ce qui change pour l'équipe

Les sources décrivent les fonctions et les données reprises, mais ne démontrent pas un coût de parc réduit ni un taux d'erreur mesuré. Un suivi ultérieur pourrait mesurer le temps de recherche d'une pièce, le nombre de doublons détectés et la complétude des fiches.

Les limites à prévoir

La qualité du registre dépend de la qualité des documents d'entrée. Un scan illisible, une ancienne immatriculation ou un compteur erroné exige une vérification. Les échéances n'ont de valeur que si elles sont maintenues à jour. Les droits d'accès et les sauvegardes protègent aussi des documents contenant des données personnelles.

L'outil n'est ni un diagnostic mécanique automatique ni une comptabilité analytique complète. Son intérêt est de présenter des faits sourcés, des anomalies visibles et un historique suffisamment fiable pour qu'un responsable puisse agir.

Repères techniques

Node.js / ExpressSQLiteAPI contrôléeDocuments PDF

Ces choix décrivent le périmètre présenté. Une reprise dans un autre contexte commence par la validation des usages, des données et des accès.