Mise en œuvre de la sérialisation pharmaceutique : le processus en 7 étapes
La sérialisation est une séquence d’étapes opérationnelles, et non un système unique. Chaque étape dépend de la précédente, et une défaillance à n’importe quel point de la chaîne génère des exceptions en aval ; c’est précisément pourquoi il est aussi important de comprendre l’ensemble du processus de sérialisation pharmaceutique pour cadrer un projet que pour le piloter au quotidien.
Étape 01 – Configuration des données de référence
Ce qui se passe : Avant l’impression de tout code, les données produits doivent être exactes et cohérentes : GTIN, hiérarchies d’emballage, codes NDC (National Drug Codes) ou identifiants équivalents, ainsi que les relations entre chaque niveau d’emballage (quelles unités s’intègrent dans quelles caisses, quelles caisses sur quelles palettes).
Responsable : C’est généralement le fabricant ou le titulaire de l’autorisation de mise sur le marché (MAH) qui est responsable des données de référence, même lorsque le conditionnement est sous-traité à un CMO/CDMO. Notre Guide de la sérialisation pharmaceutique détaille davantage les rôles au sein de la chaîne d’approvisionnement.
Systèmes concernés : Les données de référence proviennent presque toujours de l’ERP et doivent être validées avant d’être transmises à la plateforme de sérialisation L3/L4.
Délai type : Lors d’une première mise en œuvre, le nettoyage des données de référence prend couramment plusieurs semaines, soit plus que ce que la plupart des équipes prévoient au départ, car les erreurs ne deviennent évidentes que lorsqu’elles se manifestent en aval.
Points de défaillance : Un GTIN erroné ou un niveau de hiérarchie d’emballage manquant ne provoque pas d’échec immédiat. L’échec survient des semaines ou des mois plus tard, sous la forme d’une expédition refusée ou d’une vérification échouée chez un partenaire commercial ; à ce stade, l’erreur s’est déjà propagée à des milliers d’enregistrements de numéros de série. La corriger implique de rapprocher chaque unité concernée, et pas seulement de modifier un champ.
À retenir : Les erreurs de données de référence sont peu coûteuses à corriger lors de la configuration et coûteuses après la mise en production. Elles figurent aussi parmi les causes premières les plus fréquemment relevées lors des audits de validation BPF ; c’est pourquoi il est plus important qu’il n’y paraît de traiter les données de référence comme une discipline continue (et non comme une tâche ponctuelle).
Étape 02 – Génération et gestion des numéros de série
Ce qui se passe : Les numéros de série doivent être générés, attribués à des lignes de production précises et suivis de manière à ce qu’aucun numéro ne soit jamais réutilisé ni dupliqué, y compris entre différents marchés, puisque certains pays exigent des schémas de sérialisation distincts.
Responsable : Il s’agit généralement d’une responsabilité partagée entre l’équipe de sérialisation du fabricant et, en cas de production sous-traitée, le CMO/CDMO. Déterminer qui émet les numéros et comment les pools sont transférés est une question contractuelle autant que technique.
Systèmes concernés : Les pools de numéros de série sont généralement gérés au niveau L3 (site) et rapprochés au niveau L4 (entreprise) pour offrir une visibilité multisite ou entre plusieurs CMO/CDMO.
Délai type : Une fois les données de référence propres, la configuration des pools de numéros de série est généralement rapide – quelques jours plutôt que quelques semaines – mais les processus de rapprochement avec les CMO/CDMO prennent plus de temps à mettre en place et à tester.
Points de défaillance : Les numéros de série en double sont l’échec classique à cette étape : deux lignes de production puisant dans le même pool sans rapprochement adéquat, ou un CMO/CDMO émettant des numéros en dehors de la plage qui lui a été attribuée. Il en résulte une collision de numéros de série qui n’est détectée que lorsqu’une demande de vérification échoue quelque part dans la distribution.
À retenir : Pour toute entreprise travaillant avec des CMO/CDMO, la gouvernance des numéros de série (qui les émet, qui les rapproche) doit être définie avant le début de la production, et non improvisée après une collision.
Étape 03 – Impression et marquage
Ce qui se passe : Le numéro de série, le GTIN, le numéro de lot et la date de péremption sont encodés dans un code-barres 2D DataMatrix et imprimés directement sur l’emballage pendant le conditionnement, à pleine cadence de ligne.
Responsable : Les opérations de la ligne de conditionnement, généralement avec un processus de maîtrise des changements encadrant tout ce qui touche aux paramètres d’impression.
Systèmes concernés : L1 (imprimantes) et L2 (contrôleurs de ligne), intégrés au système L3 qui fournit les numéros de série et les données à imprimer.
Délai type : Une fois configurée et validée, l’impression s’effectue à la cadence de la ligne de production sans allonger le temps de cycle ; le coût opérationnel provient ici de la configuration et de la validation, et non du débit au quotidien.
Points de défaillance : La dérive d’étalonnage des imprimantes est la défaillance la plus fréquente : une imprimante légèrement déréglée produit des codes qui passent un contrôle visuel sommaire mais échouent à la vérification formelle. C’est une préoccupation centrale de toute mise en œuvre de traçabilité (track & trace) de l’étiquetage pharmaceutique : impression et vérification doivent être traitées comme un seul processus continu, et non comme deux processus distincts.
À retenir : L’impression doit suivre la cadence de la ligne de conditionnement sans devenir un goulot d’étranglement ; c’est pourquoi la vérification (l’étape suivante) a lieu immédiatement, et non comme un contrôle distinct en aval.
Étape 04 – Inspection par vision et vérification
Ce qui se passe : Immédiatement après l’impression, un système de vision relit le code pour confirmer qu’il est lisible, correctement formaté et conforme aux données prévues.
Responsable : Les opérations de la ligne de conditionnement, avec l’appui de l’assurance qualité pour les critères et seuils de vérification.
Systèmes concernés : Le matériel d’inspection par vision au niveau L1, qui transmet ses résultats au contrôleur de ligne L2 en temps réel.
Délai type : Lorsqu’elle fonctionne correctement, cette étape n’ajoute pratiquement aucun temps à la ligne : la vérification s’effectue en ligne, à la cadence de production. Le coût en temps n’apparaît que lorsqu’un code échoue et que la ligne doit s’arrêter.
Points de défaillance : Un code qui échoue à la vérification doit être rejeté avant de quitter la ligne, et non détecté en aval chez un distributeur, où un code défectueux devient un problème bien plus coûteux. Les seuils de vérification reposent généralement sur les normes internationales de qualité d’impression des codes-barres 2D (ISO/IEC 15415) ; si vous cherchez la cause de rejets récurrents, il s’agit le plus souvent d’un problème d’étalonnage ou de support d’impression plutôt que d’un problème de données.
À retenir : Tout l’intérêt de cette étape est de détecter les défaillances au point le moins coûteux possible, sur la ligne, immédiatement après l’impression, plutôt qu’après l’expédition du produit.
Étape 05 – Agrégation
Ce qui se passe : Les unités sérialisées individuelles sont liées aux caisses et aux palettes dans lesquelles elles sont conditionnées, ce qui crée une hiérarchie parent-enfant permettant au système de savoir exactement quelles unités se trouvent dans quel contenant.
Responsable : Les opérations de la ligne de conditionnement pour le processus physique, le système de sérialisation assurant la tenue de la hiérarchie dans le logiciel.
Systèmes concernés : Les systèmes L2/L3 coordonnent l’événement d’agrégation et transmettent la hiérarchie obtenue au niveau L4 pour le reporting réglementaire.
Délai type : En fonctionnement normal, l’agrégation n’ajoute que quelques secondes par caisse, mais la gestion des exceptions (voir ci-dessous) peut prendre beaucoup de temps lorsqu’elle se produit.
Points de défaillance : C’est ici que naît une grande partie des exceptions opérationnelles. Scénario courant : une caisse est ouverte pour retirer une unité défectueuse alors que l’agrégation est déjà terminée. L’enregistrement parent-enfant de la caisse surestime désormais son contenu réel et, si la correction n’est pas effectuée dans le système au moment même où elle a lieu physiquement, l’écart n’apparaît que lorsque le système d’un distributeur signale une anomalie, souvent à des centaines de kilomètres, bloquant une expédition entière plutôt que la seule caisse concernée.
À retenir : Les erreurs d’agrégation tiennent rarement à la complexité du concept ; elles viennent de ce qu’une reprise physique (reconstitution d’une caisse ou d’une palette) n’est pas accompagnée, en temps réel, de la mise à jour logicielle correspondante.
Étape 06 – Échange de données et reporting
Ce qui se passe : Les événements de sérialisation et d’agrégation sont déclarés, généralement au format EPCIS, aux systèmes internes, aux partenaires commerciaux et, sur certains marchés, aux référentiels gouvernementaux.
Responsable : Les équipes IT/systèmes gèrent l’intégration technique ; les équipes conformité sont responsables des exigences réglementaires de déclaration elles-mêmes.
Systèmes concernés : C’est là que le niveau L4 effectue l’essentiel de son travail : formater et acheminer les données EPCIS vers les CMO/CDMO, les prestataires logistiques (3PL), les grossistes et les autorités réglementaires, chacun pouvant attendre une implémentation légèrement différente de la même norme.
Délai type : Continu et automatisé une fois configuré, mais l’intégration initiale des partenaires, avec des tests sur des volumes de transactions réels et pas seulement sur des fichiers d’exemple, prend couramment plusieurs semaines par partenaire.
Points de défaillance : Un fichier EPCIS mal formé, une transmission manquée ou un partenaire utilisant un format incompatible peuvent bloquer une expédition même lorsque le produit physique et son emballage sont parfaitement conformes. Ces défaillances sont rarement imputables à une partie en particulier : il s’agit généralement de deux systèmes qui interprètent la même norme de façon légèrement différente.
C’est aussi à cette étape que le logiciel joue son rôle le plus direct dans la conformité à la DSCSA. Si vous vous demandez comment les solutions logicielles aident à répondre aux exigences de traçabilité de la DSCSA, voici la réponse : le rôle central d’une plateforme de sérialisation à cette étape est de formater les informations de transaction de manière cohérente, de les acheminer vers les bons partenaires commerciaux et de conserver un historique prêt pour l’audit, sans quoi la traçabilité à l’unité exigée par la DSCSA est tout simplement impossible à grande échelle. Notre guide pratique de mise en conformité DSCSA et notre guide sur les exigences d’interopérabilité DSCSA 2023 approfondissent l’aspect réglementaire de cette étape.
Une remarque sur la validation s’impose également ici. Toute modification d’un système de sérialisation (un nouveau marché, une nouvelle ligne de conditionnement, une mise à jour logicielle) doit faire l’objet d’une validation conformément aux BPF et aux exigences du 21 CFR Part 11. Les équipes qui considèrent la validation comme une tâche de configuration ponctuelle, plutôt que comme un exercice à reprendre à chaque changement, sont généralement celles qui doivent la refaire dans l’urgence à chaque évolution.
À retenir : L’échange de données est moins une question de technologie que de cohérence : chaque partenaire doit recevoir des données correctement formatées, à temps, à chaque fois.
Étape 07 – Distribution, délivrance et désactivation
Ce qui se passe : À mesure que le produit circule dans la chaîne de distribution et atteint finalement une pharmacie ou un hôpital, chaque unité sérialisée est vérifiée puis désactivée au moment de sa délivrance, ce qui la retire de la circulation active dans le système de traçabilité.
Responsable : Les grossistes et les prestataires logistiques (3PL) pour la vérification en transit ; les pharmacies et les hôpitaux pour le contrôle final à la délivrance.
Systèmes concernés : Vérification au point de délivrance selon le modèle de la DSCSA, ou contrôle auprès d’une base de données centralisée selon le modèle de la directive européenne sur les médicaments falsifiés (FMD). Les deux cadres fonctionnent différemment sur ce point, comme l’explique notre guide de conformité à la FMD.
Délai type : Cette étape se poursuit tout au long de la présence du produit dans la chaîne d’approvisionnement et ne prend fin qu’à sa désactivation.
Points de défaillance : Il s’agit du dernier point de contrôle avant qu’un produit n’atteigne le patient, et il dépend entièrement de la transmission de données propres et à jour par chaque acteur en amont. Un maillon faible n’importe où dans la chaîne (données de référence de mauvaise qualité, gestion des pools peu fiable, distributeur qui omet la vérification) dégrade la fiabilité de cette étape finale, même si la défaillance n’y trouve pas son origine. Notre guide sur la gestion des rappels de produits pharmaceutiques grâce à la traçabilité explique ce qui se passe lorsque cette étape doit être déroulée en sens inverse.
À retenir : La désactivation est la ligne d’arrivée, mais sa fiabilité reflète en réalité la qualité d’exécution de chacune des étapes précédentes.
