Retour au blog
Actualités
13 octobre 2026

EUCARIS ICM 3.1 : nouveaux champs obligatoires dans l'eCoC, contrôles renforcés et pourquoi les envois non suivis seront rejetés

EUCARIS ICM 3.1 : nouveaux champs obligatoires dans l'eCoC, contrôles renforcés et pourquoi les envois non suivis seront rejetés

L'IVI Checking Module (ICM) est le jeu de règles de validation publié par EUCARIS et appliqué par les points d'accès nationaux à chaque eCoC entrant au format IVI 2.0. Si un fichier XML enfreint une seule règle, l'envoi est rejeté et le véhicule ne peut pas être immatriculé à partir de cet enregistrement. La version 3.1 est parue le 28 septembre 2026, trois semaines après la version 3.0 du 5 septembre.

Ce qui change dans la version 3.1

La publication du 28 septembre est modeste, mais chacun de ses points peut transformer un fichier jusqu'ici accepté en fichier rejeté :

  • Un nouveau XSD IVI 2.0 avec une énumération étendue pour ExhaustEmissionLevel. Les fichiers générés avec le schéma précédent peuvent échouer à la validation du schéma.
  • PoweredAxle devient obligatoire pour les catégories de véhicules M, N, T et C.
  • La règle LoadableAxleIndicator a été corrigée : l'indicateur doit être N lorsque NumberOfAxles est inférieur à 2 (auparavant inférieur ou égal à 2).
  • InServiceMaximumPermissibleLadenMassAxle ne peut plus être fourni seul. Il exige désormais InServiceMaximumPermissibleLadenMassAxleCountry ou InServiceMaximumPermissibleLadenMassAxleTrafficRegulation.
  • La BodyWorkTable ne peut plus être omise lorsque les règles rendent ses champs obligatoires. Dans les mêmes conditions, la table elle-même doit être présente.

Et dans la version 3.0, trois semaines plus tôt

La version 3.0 du 5 septembre était une publication plus importante, issue des discussions sur les véhicules à plusieurs étapes au sein du groupe de travail EReg :

  • Plus de 50 champs, concernant les essieux, les dimensions, les marquages, les convertisseurs d'énergie et la classe du véhicule, ne sont plus obligatoires que pour les véhicules complets (StageOfCompletion = C). Cela facilite les envois pour les véhicules incomplets et complétés, mais change aussi les champs qu'un véhicule complet doit contenir.
  • Le contrôle de la réception par type multiétapes a été ramené à sa forme initiale : PreviousStageTypeApprovalNumber doit différer de TypeApprovalNumber.
  • ActualMass doit être inférieure ou égale à TechnicallyPermissibleMaximumLadenMass pour les catégories M, N, O et L. Le « ou égale » manquant a été ajouté.
  • TyreFittedProductionIndicator doit porter une valeur pour chaque pneumatique.
  • Un VehicleIdentificationNumber des catégories T, C, R et S (règlement 167/2013) peut désormais contenir I, O et Q.
  • Le zéro n'est plus accepté dans les champs techniques de numérotation : ManufacturerStageNumber, GearNumber, FinalDriveNumber, AxleNumber, TyreNumber et huit autres.
  • Corrections des chemins d'imbrication des règles R214 et R215, de la position de CategoryHybridElectricVehicle, des niveaux inversés de TypeINox et TypeINmhc, et d'une erreur de fuseau horaire dans le contrôle de la date de production.

Neuf publications en sept mois

Ce n'est pas un cas isolé. Depuis que l'ICM porte une information de version, en février 2026, il est passé de 2.3 à 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0 et maintenant 3.1. Les publications précédentes ont aussi ajouté du contenu obligatoire : AxleAirSuspensionOrEquivalentIndicator est devenu obligatoire pour la catégorie O, MechanicalCouplingCanBeFittedApprovalMark et ApprovalNumber ont été ajoutés, SignerName a été ajouté, TestFamilyIdentifierValue a reçu des contrôles de format, et un nouveau XSD IVI 2.0 daté du 10 juin a remplacé le schéma précédent.

En pratique, le jeu de règles change à peu près une fois par mois, et ce qui compte comme champ obligatoire est une cible mouvante. Une intégration construite une fois pour une version donnée de l'ICM n'est correcte que jusqu'à la publication suivante.

Un rejet, pas un avertissement

Le point d'accès national n'accepte pas un fichier qui enfreint une règle de l'ICM. Un eCoC accepté en août peut être rejeté en octobre sans aucun changement du côté du constructeur. Pour un constructeur qui génère du XML IVI à partir d'un modèle, d'un outil de conversion ou d'un script interne écrit pour une version antérieure de l'ICM, le premier signe est généralement un rejet au NAP, et parfois un véhicule bloqué au guichet d'immatriculation.

Le coût d'une erreur augmente aussi. Comme nous l'avons décrit dans notre note surle calendrier du KBA pour IVI 2.0, à partir de la version 2.x les enregistrements envoyés ne peuvent plus être supprimés ; le seul remède est un enregistrement de correction. Réussir le fichier du premier coup compte plus qu'avant.

Comment CoCDesk gère les publications de l'ICM

Suivre l'ICM fait partie de ce que fait CoCDesk, ce n'est pas quelque chose que nos clients doivent faire eux-mêmes :

  • Nous suivons chaque publication de l'ICM et du XSD par EUCARIS et intégrons les nouvelles règles au moteur de validation de la plateforme peu après leur parution, de sorte que CoCDesk valide contre le jeu de règles que les points d'accès nationaux appliquent réellement.
  • Chaque eCoC est vérifié contre le jeu de règles ICM et le XSD en vigueur avant de quitter votre système. Un fichier incomplet ou non conforme n'est jamais envoyé, donc jamais rejeté.
  • Les nouveaux champs obligatoires apparaissent dans l'interface : le champ est mis en évidence et la règle expliquée, pour que votre équipe sache exactement quoi ajouter et pourquoi.
  • Lorsqu'un champ devient obligatoire, il est mappé une seule fois depuis votre ERP, votre MES ou vos données de réception par type. Personne ne modifie le XML à la main.
  • La logique StageOfCompletion de la version 3.0 est appliquée automatiquement, de sorte que les véhicules incomplets, complétés et complets sont chacun validés contre le bon sous-ensemble de règles.
  • Chaque envoi conserve une trace horodatée de la version des règles avec laquelle il a été validé, prête pour les contrôles de conformité de la production.

Votre chaîne eCoC est-elle prête pour l'ICM 3.1 ?

Si vos eCoC sont produits à partir d'un modèle, d'un convertisseur ou d'un script, la version 3.1 est un bon moment pour les vérifier. Réservez une démo en direct et nous passerons vos propres données véhicules dans le jeu de règles en vigueur.

Réserver une démo en direct

Prêt pour le déploiement eCoC dans l'UE ?

Réservez une démo gratuite et découvrez comment COCDESK peut rendre votre processus eCoC opérationnel dans tous les États membres de l'UE.