Une mise à niveau au sein d’une installation de niveau BSL-3 ou BSL-4 se limite rarement au composant qui a été physiquement modifié. Avant qu’une équipe de projet puisse décider de ce qu’il faut tester, elle doit déterminer ce qui a réellement changé — et c’est cette question de délimitation, et non la méthode de test elle-même, qui détermine si les travaux de réception sont défendables. Se tromper sur cette délimitation, dans un sens comme dans l’autre, engendre un coût réel : si elle est trop restrictive, une interface non testée est remise en service avec une fonction de confinement non vérifiée ; si elle est trop large, le projet fait retester des systèmes qui n’ont jamais été modifiés.
Les limites de la mise aux normes doivent inclure les modifications physiques et fonctionnelles
| Interface de mise à niveau | Problème de délimitation | Acceptation - planification - conséquence |
|---|---|---|
| Passages et joints d'étanchéité | Cette modification a-t-elle compromis l'intégrité d'une pénétration ou d'un joint de l'enceinte de confinement ? | Prévoir l'inspection et les essais du joint concerné ; ne pas en déduire une portée ou une limite générale pour les essais d'étanchéité des locaux. |
| Zones de pression | Ce changement a-t-il modifié une relation de pression concernée ? | Prévoir une vérification du sens du flux d'air pour cette relation. |
| Circuits d'échappement | La mise à niveau a-t-elle modifié le tracé d'un circuit d'échappement ou son raccordement ? | Intégrez la fonction d'échappement concernée dans le périmètre du test. |
| Commandes, alarmes et verrouillages | La configuration de contrôle, la logique ou l'état d'une interface ont-ils changé ? | Testez les commandes, les alarmes et les verrouillages concernés pour tous les états de l'interface modifiés. |
| Services publics, équipements de transfert et interfaces de gestion des déchets | Cette modification a-t-elle entraîné un changement au niveau d'une connexion physique ou d'une dépendance fonctionnelle au niveau de l'une de ces interfaces ? | Considérez la fonction concernée comme faisant partie du périmètre de modification et choisissez les moyens de vérification en fonction du risque associé au projet. |
La mise à niveau d'un système de confinement est rarement une action isolée. Les travaux effectués sur une interface ont souvent des répercussions sur d'autres interfaces qui partagent une connexion physique ou une dépendance fonctionnelle, même lorsque personne n'avait prévu ce résultat. A passage de câble ou de cordon L’ajout d’une paroi de confinement constitue un changement physique, mais il peut également s’agir d’un changement fonctionnel s’il modifie la différence de pression de part et d’autre de la barrière qu’il traverse. Une mise à jour de la logique de commande liée à une porte ou à un sas constitue un changement fonctionnel, même si aucun matériel n’a été remplacé. La première tâche de l’équipe de projet n’est pas de procéder à des essais, mais de recenser les limites physiques et les relations fonctionnelles qui ont été modifiées par les travaux de modernisation, quelle que soit l’apparente insignifiance de l’intervention à l’époque.
Cela est important car les performances de confinement sont interdépendantes. Une pénétration, une zone de pression, un circuit d’évacuation, un point de contrôle, un raccordement aux réseaux et une interface de gestion des déchets ne fonctionnent pas de manière indépendante ; chacun dépend du maintien de l’état prévu des autres. Lorsqu’une rénovation modifie l’un de ces éléments, la délimitation de “ ce qui a changé ” doit s’étendre à toutes les fonctions qui dépendent de la condition modifiée, et pas seulement au composant qui a été physiquement ouvert ou remplacé. Une modification de la zone de pression induite par une nouvelle pénétration est une conséquence fonctionnelle d’une action physique, et les deux doivent s’inscrire dans la même limite d’acceptabilité.
La conséquence pratique pour la planification du projet est que la limite de modification doit être définie avant la rédaction de la liste des tests, et non déduite de celle-ci. Si l’équipe commence par se demander “ quels tests effectuons-nous habituellement après ce type de travaux ”, elle risque de ne tester que la modification physique évidente et de passer à côté des conséquences fonctionnelles qui se répercutent sur l’ensemble du système. Si, au contraire, elle commence par se demander “ quelles interfaces — pénétrations, zones de pression, voies d’évacuation, commandes, réseaux techniques, équipements de transfert, interfaces de gestion des déchets — ont été perturbées, physiquement ou fonctionnellement, par cette modernisation ”, la liste de tests découle alors d’une délimitation fondée sur des preuves plutôt que sur l’habitude.
Lorsque la mise à niveau se limite à un seul composant bien isolé, sans dépendance partagée, le périmètre reste restreint et les travaux de validation restent ciblés. Lorsque la mise à niveau touche un service partagé, un système de contrôle partagé ou une fonction ayant des éléments dépendants en aval, le périmètre doit être élargi pour inclure ces éléments dépendants, même si ceux-ci n’ont pas été physiquement modifiés. Déterminer quelle condition s’applique est la première décision que l’équipe de projet doit prendre, et celle-ci doit être formulée explicitement, sans être déduite a priori de la portée de l’ordre de travail de maintenance.
Les données existantes ne restent exploitables que pour des configurations inchangées
| Condition relative à la preuve | Utilisation autorisée | Implication d'acceptation |
|---|---|---|
| La configuration reste inchangée et les éléments de preuve restent valables | Conservez cet enregistrement comme référence pour cette configuration inchangée. | Le dossier ne permet pas de conclure à l'acceptation d'une interface modifiée. |
| Une modification de l'interface peut avoir une incidence sur un résultat antérieur ou adjacent. | Ne reprenez pas ce résultat tel quel sans en réévaluer la pertinence. | Inclure le résultat concerné dans le périmètre de la nouvelle vérification. |
| La concordance des configurations ou l'applicabilité des éléments de preuve n'est pas claire | Considérez l'applicabilité comme une inconnue propre à chaque projet. | Conservez la fonction associée dans le périmètre de la révision jusqu'à ce que la relation soit établie. |
Les dossiers de qualification et de mise en service issus de la construction initiale de l'installation ou d'une modernisation antérieure constituent la preuve d'une configuration spécifique à un moment donné. Cette preuve ne reste valable que tant que la configuration qu'elle décrit reste inchangée. La question relative à l'acceptation de la modernisation ne porte pas sur le caractère adéquat de la preuve antérieure au moment où elle a été établie — ce qui était très certainement le cas —, mais sur le fait de savoir si la configuration qu'elle décrit existe toujours après les travaux actuels.
C'est là que l'acceptation d'une rénovation diffère de la mise en service d'une nouvelle construction. Dans une nouvelle construction, toutes les preuves sont établies par rapport à la configuration finale, telle que réalisée. Dans une rénovation, le projet hérite d'un mélange : certains systèmes sont conservés tels quels, d'autres ont été directement modifiés, et d'autres encore se situent entre les deux — ils n'ont pas été directement modifiés, mais sont adjacents ou dépendent d'un élément qui l'a été. L'équipe de projet doit classer chaque système dans l'une de ces catégories avant de décider quelles preuves s'y appliquent.
La troisième catégorie est la plus délicate. Une interface modifiée peut invalider un résultat adjacent, même si le système adjacent n’a jamais été ouvert, car la qualification antérieure de ce dernier reposait sur une condition — une relation de pression, un trajet d’écoulement d’air, un état de commande — que la modernisation a pu altérer. Reprendre un dossier de qualification sans réévaluer si l’hypothèse sous-jacente est toujours valable revient à traiter les données héritées comme si elles se renouvelaient d’elles-mêmes, ce qui n’est pas le cas.
Lorsque la correspondance entre l’état réel de la mise à niveau et l’état décrit dans le dossier de qualification est claire et inchangée, le dossier existant peut servir de référence et il n’est pas nécessaire de le refaire. Lorsque cette concordance n’est pas claire — c’est-à-dire lorsque l’équipe ne peut pas confirmer si la modernisation a remis en cause une hypothèse sur laquelle reposaient les preuves antérieures —, la position la plus honnête consiste à considérer l’applicabilité comme une question en suspens et à maintenir la fonction concernée dans le périmètre de la révision jusqu’à ce que la relation soit établie, plutôt que de se rabattre par défaut sur une acceptation totale ou une nouvelle série complète de tests. Il s’agit là autant d’une question de rigueur documentaire que d’une question technique : le dossier d’acceptation de la mise à niveau doit démontrer, pour chaque enregistrement hérité, pourquoi il a été jugé toujours applicable, et non pas simplement qu’il existe.
Les passages, les joints et les relations de pression doivent faire l'objet de contrôles ciblés
| Interface modifiée | Données probantes ciblées | Ce que le contrôle permet de vérifier | Limite de la preuve |
|---|---|---|---|
| Passage de câbles ou autre traversée murale | Inspection et contrôle du joint d'étanchéité concerné après un remplacement ou une réparation | Preuves de la modification de la pénétration et de son étanchéité | Elle n'établit pas de champ d'application universel en matière d'étanchéité des pièces, ni de limite fixe, ni d'homologation des produits. |
| Interface de porte à joint pneumatique | Vérification du scellé concerné et de toutes les alarmes ou verrouillages concernés après le remplacement du scellé ou une mise à jour du système de contrôle | Éléments attestant de la modification des fonctions de l'interface de la porte | Il n'accepte pas les systèmes inchangés provenant d'ailleurs. |
| Relation de pression entre les zones concernées | Vérification de la direction du flux d'air pour la relation concernée | Preuves d'une modification de la relation entre la pression et la zone | Il ne valide pas les zones adjacentes non modifiées. |
Une fois la limite de modification définie, les travaux de réception doivent fournir des preuves adaptées à chaque interface spécifique, plutôt que de recourir à un test générique appliqué de manière uniforme à l'ensemble de l'installation. Les passages de tuyauterie, les joints d'étanchéité et les relations de pression présentent des comportements différents les uns des autres, et les preuves établissant les performances de l'un ne sont pas transposables aux autres.
Une traversée murale — destinée aux câbles, cordons ou autres passages de services — est évaluée au moyen de inspection et essais de ce joint spécifique après la modification ou la réparation qui l’a affecté. Cela fournit une preuve de cette pénétration et de son étanchéité ; cela n’établit pas pour autant un niveau d’étanchéité applicable à l’ensemble de la pièce ni une limite universelle, et cela ne donne aucune indication sur l’état des autres pénétrations du même mur qui n’ont pas été modifiées. Lorsqu’un établissement utilise un passage dédié pour les cordons et câbles, comme c’est le cas avec un Dispositif de pénétration de type Vacu-Pass, le contrôle ciblé porte sur ce port spécifique et son interface d'étanchéité, et non sur l'ensemble du mur.
A interface porte-joint pneumatique implique un besoin de vérification qui lui est propre. Lorsqu'un le joint de porte a été remplacé ou une mise à jour du système de commande a été effectuée Si le fonctionnement des verrouillages ou des alarmes de la porte a été modifié, le contrôle ciblé doit porter sur le joint lui-même ainsi que sur toute fonction d’alarme ou de verrouillage liée au nouvel état de ce joint. Ces éléments de preuve établissent le fonctionnement de l’interface de la porte ; ils ne prennent pas en compte les systèmes restés inchangés ailleurs dans le même sas ou la même suite, même lorsque ces systèmes partagent la même plateforme de contrôle.
Une relation de pression entre deux zones nécessite une vérification du sens du flux d’air spécifique à cette relation. Cela se distingue à la fois du contrôle de pénétration et du contrôle des portes, car une relation de pression est une condition dynamique au niveau du système plutôt qu’une condition d’étanchéité statique — elle dépend du fait que le circuit d’évacuation, l’équilibre de l’alimentation et l’état des portes se comportent tous simultanément comme prévu. La vérification de cette relation pour une paire de zones concernées fournit des preuves valables pour cette paire ; elle ne fournit aucune indication concernant une paire de zones adjacentes non concernées, même lorsque les deux paires partagent la même branche d'évacuation en amont.
Concrètement, cela signifie qu’un plan de réception des travaux de mise en conformité ne peut pas se fonder sur un seul type d’essai pour couvrir plusieurs catégories d’interfaces. Lorsque les travaux de mise en conformité concernent simultanément une pénétration, un joint de porte et une relation de pression, le projet nécessite trois ensembles de données distincts, chacun portant sur sa propre interface, les limites de chaque résultat étant clairement définies afin qu’elles ne puissent pas être interprétées ultérieurement comme couvrant plus que ce qu’elles englobent réellement.
Les commandes et les verrouillages doivent faire l'objet de tests dans tous les nouveaux états de l'interface
Les commandes et les verrouillages posent un défi de validation différent de celui des joints d'étanchéité ou des zones de pression, car leur fonctionnement est défini par leur comportement dans différents états plutôt que par une seule condition statique. Un système de commande ou un verrouillage qui passe avec succès un contrôle dans un état donné — porte fermée, système au repos, pression de fonctionnement normale — n'a pas pour autant démontré qu'il se comportait correctement dans tous les états que la modernisation a pu introduire ou modifier.
Lorsqu’une mise à niveau modifie la configuration d’un système de commande ou sa logique sous-jacente, la logique nouvelle ou modifiée doit être testée pour chaque état d’interface qu’elle régit, et pas seulement pour l’état qu’il est le plus pratique de tester. Un verrouillage de porte lié à une différence de pression, par exemple, a une intention de conception qui couvre au moins l’état normal, l’état de transition et tout état de défaut ou d’alarme. Si seul l’état normal est vérifié, les travaux de réception de la modernisation ont confirmé que la porte se comporte correctement en l’absence de problème, ce qui est l’état le moins susceptible de révéler une erreur induite par la modification.
Cela revêt une importance particulière lorsque la mise à niveau a consisté en une mise à jour de la logique de commande plutôt qu’en un remplacement matériel. Une modification de la logique peut altérer la manière dont une condition d’alarme est évaluée, dont un verrouillage réagit à une condition limite, ou dont deux boucles de commande auparavant indépendantes interagissent désormais, sans qu’il y ait le moindre changement physique visible. Comme ce changement est invisible au niveau matériel, la seule façon de s’assurer qu’il se comporte comme prévu est de faire passer le système par chacun des états que la nouvelle logique est censée gérer et de vérifier que la réponse correspond bien à la conception prévue, y compris les états représentant un écart ou une condition de rétablissement plutôt qu’un fonctionnement en régime permanent.
L'équipe chargée du projet doit ici identifier, pour chaque commande ou verrouillage modifié, l'ensemble complet des états que la mise à niveau a introduits ou modifiés — non seulement les états prévus par la conception d'origine, mais aussi tout nouvel état créé par la mise à niveau elle-même — et confirmer que chaque état produit la réponse prévue. Lorsque la modernisation a modifié une plateforme de commande partagée, cette obligation s’étend à chaque fonction de verrouillage ou d’alarme régie par cette plateforme, même si une seule fonction spécifique était la cible visée par la modification.
Les réparations ou les écarts peuvent élargir le champ d'application de la nouvelle vérification
| Déclencheur | Pourquoi le champ d'application actuel pourrait ne plus être suffisant | Traitement nécessaire |
|---|---|---|
| Écart constaté lors de la vérification | La fonction concernée ne renvoie plus de résultat sans qualification pour la configuration testée. | Noter l'écart, déterminer la limite concernée et consigner toute réparation et toute nouvelle vérification. |
| Réparation d'une interface défectueuse | La configuration après la réparation diffère de celle qui avait permis d'obtenir les preuves antérieures. | Consignez la réparation effectuée et revérifiez le bon fonctionnement de la fonction concernée. |
| Modification susceptible d'affecter un résultat adjacent | Une modification de l'interface peut invalider les preuves relatives à une fonction associée. | Réévaluez l'enregistrement adjacent et élargissez le champ d'application de la nouvelle vérification là où celle-ci n'est plus applicable. |
| Opération de maintenance ou de décontamination ayant une incidence sur une fonction | L'état de rétablissement fait partie de la frontière fonctionnelle concernée. | Vérifier la fonction de reprise concernée en fonction des risques liés au projet et consigner la configuration ainsi que les éléments justificatifs. |
Les tests d'acceptation peuvent eux-mêmes fournir de nouvelles informations qui modifient l'étendue de ce qui reste à vérifier. Un écart constaté au cours de la vérification, ou un réparation effectuée sur une interface À la suite de cette vérification, il ne s'agit pas d'une étape close une fois le problème immédiat résolu : c'est un élément déclencheur qui oblige l'équipe de projet à réexaminer si le périmètre de test initial couvre toujours l'ensemble de ce qui doit faire l'objet d'une validation.
Un écart constaté lors de la vérification signifie que la fonction concernée ne présente plus de résultat valide pour la configuration testée. Cela diffère d’un test réussi sans écart : dès qu’un écart survient, la fonction reste dans un état non résolu jusqu’à ce qu’elle soit soit retestée avec succès, soit que l’écart soit traité et documenté d’une autre manière. Une réparation effectuée sur une interface concernée modifie la configuration elle-même : le système après la réparation n’est plus le même que celui décrit par les preuves antérieures, même si la réparation visait à rétablir l’intention de conception initiale, car l’état « tel que construit » a changé au cours du processus menant à ce résultat.
Le cas le plus grave est celui où un écart ou une réparation révèle qu’un résultat adjacent, que l’on supposait auparavant inchangé, pourrait ne plus être valable. Cela renvoie directement aux questions soulevées précédemment concernant les limites et l’applicabilité des preuves : une réparation sur une interface peut invalider l’hypothèse sur laquelle reposait un dossier de qualification adjacent, même si le système adjacent n’a jamais été directement concerné par la mise à niveau ou la réparation. Prendre conscience de cela exige que l’équipe de projet considère chaque écart et chaque réparation comme une occasion de réexaminer les limites, et non pas simplement de corriger le problème immédiat avant de passer à autre chose.
Les fonctions de maintenance ou de décontamination et de remise en état méritent le même traitement lorsque la mise à niveau les a affectées. Une fonction de remise en état — c’est-à-dire la capacité du système à revenir à son état de confinement prévu après un intervention de maintenance ou de décontamination — fait partie de la limite fonctionnelle que la mise à niveau a pu perturber, même si ce n’est pas la première fonction à laquelle une équipe pense pour effectuer des tests. Lorsque la mise à niveau a modifié une interface liée à la reprise, la fonction de reprise elle-même doit être vérifiée en fonction du risque concerné, la configuration et les preuves qui en résultent devant être consignées avec le reste du dossier de réception.
Les registres de mise en production doivent distinguer les modifications testées des systèmes non modifiés
| Section « Enregistrements publiés » | Champ obligatoire | Valeur de décision |
|---|---|---|
| Configuration testée et limites des modifications | Définir la configuration physique et fonctionnelle visée par les travaux de réception de la mise à niveau. | Précise à quoi s'appliquent les nouveaux éléments de preuve. |
| Interfaces et fonctions testées | Énumérez les passages, joints, relations de pression, voies d'évacuation, commandes, alarmes, verrouillages ou fonctions de récupération concernés qui ont effectivement été vérifiés. | Indique quelles fonctions modifiées ont fait l'objet de vérifications ciblées. |
| Éléments de preuve existants conservés | Identifiez les enregistrements antérieurs utilisés uniquement pour des configurations inchangées, pour lesquelles les éléments probants restent applicables. | Distingue les données de référence acceptées des résultats des nouveaux essais de mise à niveau. |
| Écarts, réparations et nouvelle vérification | Consignez chaque anomalie ou réparation, ainsi que les éléments de preuve recueillis à la suite de celle-ci. | Montre comment les exceptions ont influencé la portée finale du test et l'ensemble des éléments de preuve. |
| Systèmes intacts | Identifier les systèmes situés en dehors du périmètre de modification testé. | Empêche que la version de mise à niveau ne soit considérée comme une nouvelle preuve d'acceptation pour les systèmes qui n'ont pas été modifiés. |
Le verdict final concernant la réception d’une mise à niveau BSL-3/4 ne repose pas sur les résultats des essais, mais sur la manière dont le procès-verbal de réception rend compte de la relation entre ce qui a été testé et ce qui ne l’a pas été. Un procès-verbal de réception qui se contente d’indiquer que l’installation a réussi ses essais de réception, sans distinguer les modifications testées des systèmes non modifiés, crée une lacune documentaire dont le propriétaire de l’installation héritera indéfiniment : toute personne qui lira ce procès-verbal ultérieurement n’aura aucun moyen de savoir quels systèmes sont réellement couverts par les nouvelles preuves.
Le rapport doit identifier explicitement la configuration testée et les limites de la modification, afin que toute personne qui l'examinera ultérieurement comprenne exactement quel était le périmètre physique et fonctionnel couvert par les travaux de réception de la mise à niveau. Il doit énumérer les interfaces et fonctions spécifiques effectivement vérifiées — les traversées, les joints d'étanchéité, les relations de pression, les voies d'évacuation, les commandes, les alarmes, les verrouillages ou les fonctions de récupération ayant fait l'objet de contrôles ciblés — plutôt que de décrire les travaux en termes généraux qui pourraient être interprétés comme plus larges que ce qui a été réellement effectué. Il doit préciser quels dossiers de qualification antérieurs ont été conservés comme preuves de référence, et pour quelles configurations inchangées ces preuves restent applicables, afin que la distinction entre les nouveaux essais et les preuves héritées soit traçable plutôt qu’implicite.
Lorsqu’un écart ou une correction est survenu au cours du processus de réception, le compte rendu doit indiquer comment cet événement a été résolu et quelles preuves ont été produites par la suite, afin qu’un examinateur ultérieur puisse comprendre comment le périmètre final des tests a été défini, plutôt que de supposer que le plan initial a été exécuté sans aucune exception. Enfin, le compte rendu doit identifier les systèmes qui se situent totalement en dehors du périmètre de modification testé — c’est-à-dire les systèmes que la mise à niveau n’a pas affectés, ni physiquement ni fonctionnellement — afin que la validation ne puisse pas être interprétée à tort, par la suite, comme une nouvelle preuve d’acceptation pour ces systèmes non concernés.
Cette structure sert davantage les intérêts à long terme du propriétaire de l’installation que le projet de mise en conformité immédiat : toute mise en conformité, audit ou inspection future dépendra de la capacité à déterminer, à partir du seul dossier, quels systèmes contiennent des preuves actuellement applicables et lesquels contiennent des preuves issues d’une configuration antérieure qui pourrait ne plus être valable. Lorsqu’un projet fournit à QUALIA les détails de la configuration de la mise à niveau, les interfaces concernées et la base de risque dans le cadre d’un devis ou d’une analyse de projet, ce sont ces mêmes informations de délimitation qui permettent à des équipements tels que les portes APR, les passages de cordons et de câbles, ou composants de filtration in situ d'être configurées et documentées en fonction de la portée réelle de la modification, plutôt qu'en se basant sur une hypothèse générique de ce qu'impliquait la mise à niveau.
Questions fréquemment posées
Q : Chaque mise en conformité aux normes BSL-3/4 nécessite-t-elle de procéder à de nouveaux contrôles de l'ensemble de l'installation ?
A : Le périmètre de validation doit commencer par les limites physiques et fonctionnelles du changement, puis s'étendre à tous les endroits où une interface modifiée pourrait invalider les preuves relatives à une fonction associée. Les systèmes non modifiés ne peuvent rester en dehors du nouveau périmètre de test que si leur configuration reste inchangée et si les preuves existantes restent applicables.
Q : Quelles informations relatives au projet faut-il rassembler avant de finaliser le plan de réception des travaux de rénovation ?
A : Documenter la configuration modifiée, les percées concernées, les relations de pression, les voies d'évacuation, les dispositifs de contrôle, les réseaux techniques, les équipements de transfert et les interfaces de déchets, ainsi que les dossiers de qualification proposés comme référence. Identifier également les écarts connus, les réparations, les opérations de maintenance et les activités de récupération afin de pouvoir évaluer leur incidence sur le périmètre d'essai avant la mise en service.
Q : Un enregistrement de qualification antérieur peut-il être réutilisé après une modification d'une interface voisine ?
A : Uniquement après avoir vérifié que la configuration enregistrée n'a pas été modifiée et que les éléments probants restent valables. Si la modification apportée à l'interface est susceptible d'influencer le résultat antérieur, maintenez cette fonction connectée dans le périmètre de la révision jusqu'à ce que son applicabilité soit établie ou qu'elle fasse l'objet d'une nouvelle vérification.
Q : Le fait qu'un test effectué sur un passage de câble ou un joint de porte modifié se révèle concluant signifie-t-il que le système de confinement environnant est conforme ?
A : Il fournit des preuves concernant la pénétration concernée, le joint d'étanchéité et toute autre fonction effectivement testée, telle qu'une alarme, un verrouillage ou une relation de pression concernés. Il ne doit pas être considéré comme une preuve de conformité pour les zones adjacentes non concernées ni comme une preuve d'une limite générale d'étanchéité de la pièce.
Q : À quel moment faut-il élargir le champ de la revérification lors des travaux de réception ?
A : Développez cette section lorsqu'un écart, une réparation, une modification de l'interface ou un état de maintenance ou de décontamination affecté rend les preuves initiales incertaines pour une autre fonction. Enregistrez l'événement, définissez la nouvelle limite concernée et associez les preuves de revérification qui en résultent à la configuration finale testée.
Q : Comment un acheteur peut-il comparer les plans de réception proposés pour des travaux de rénovation ?
A : Vérifiez que chaque plan établit une correspondance entre chaque interface affectée et la fonction ainsi que les preuves qu’il permettra de valider, explique comment les enregistrements existants seront examinés pour s’assurer de leur applicabilité continue, et définit la manière dont les écarts ou les corrections seront traités. Le dossier de mise en production doit également distinguer les modifications récemment testées, les preuves de référence conservées, les exceptions résolues et les systèmes qui n’ont pas fait l’objet d’un nouveau test.





















