Nous avons publié l'intégralité de notre Vendor Assurance Pack — y compris ce que nous n'avons pas

Voici comment fonctionne réellement l'achat de logiciels dans une entreprise réglementée. Les opérations choisissent l'outil en semaine deux. La Qualité et la sécurité informatique commencent leur examen en semaine quatre. Le questionnaire arrive chez le fournisseur en semaine six — quarante onglets, avec une demande de catégorisation GAMP que le fournisseur n'a jamais couchée sur papier. Quelque part vers la semaine quatorze, tout le monde se met d'accord, et ce qui a bloqué n'a jamais été le produit.

Nous avons été suffisamment souvent dans cette situation pour conclure que l'ordre est mauvais. Nous avons donc publié les réponses en amont.

*Mise à jour du 23 août 2026 : le pack est réédité en v1.1 après une vérification complète de chaque statut par rapport à la production en cours. Les modifications vont dans les deux sens — les éléments relatifs à la sauvegarde à long terme et aux exercices de restauration sont clôturés, la première révision périodique est achevée, l'élément relatif au PDF par enregistrement est affiné, et la voie de certification est reformulée avec ISO 27001 en priorité ; l'entrée concernant le pare-feu a été corrigée à la hausse. La section contrôle documentaire du pack liste chaque modification.*

Contenu du document

Dix-huit sections, organisées pour qu'un examinateur puisse accéder directement à sa partie. Un responsable qualité a besoin de l'index QMS, de la catégorisation GAMP 5 et des mappages Annex 11 et Part 11. La sécurité informatique a besoin de la topologie d'hébergement, de l'architecture de sécurité et du CAIQ-Lite. Un DPO a besoin de la répartition responsable de traitement/sous-traitant, du registre des sous-traitants et de la section gouvernance de l'IA. Les achats ont besoin du statut de certification, de la posture de continuité et de la répartition des responsabilités. Le document s'ouvre sur un tableau indiquant à chacun les sections à consulter.

Les mappages de clauses en constituent le cœur. Chaque clause de Annex 11 — les dix-sept — avec ce que nous faisons à ce sujet et où se trouvent les preuves. Puis 21 CFR Part 11 : les contrôles §11.10, les dispositions relatives aux signatures §11.50 et §11.70, et les exigences en matière de signatures électroniques §11.100, §11.200 et §11.300. Deux de ces lignes sont marquées comme relevant de *votre* obligation et non de la nôtre, car elles ne peuvent pas être assumées par un fournisseur, et prétendre le contraire laisserait une lacune qui ne se révèle qu'au cours d'une inspection.

Et ce qui n'y figure pas

C'est la partie qui valait la peine d'écrire ce document. Le §13 est un tableau de statut de certification et le §17 est une liste complète des points ouverts ; ensemble, ils indiquent clairement :

• Nous ne disposons pas de SOC 2 Type II. Il est délibérément séquencé après ISO 27001 — pour une clientèle européenne, ISO 27001 est le certificat demandé lors des audits fournisseurs — et sera ajouté dès qu'un client l'exigera.
• Nous ne disposons pas encore de la certification ISO 27001. Le SMSI a été formellement ouvert en août 2026 et la certification par un organisme accrédité est visée pour fin 2026 à début 2027. Tant que le certificat n'existe pas, le pack indique *non détenu*.
• Notre pare-feu applicatif web applique cinq règles personnalisées de limitation de débit, mais aucun jeu de règles OWASP managé. Le niveau Standard de Front Door ne permet pas d'en associer un — cela nécessite le niveau Premium. *Corrigé le 2 août 2026 : ce point indiquait précédemment que le pare-feu ne comportait aucune règle et ne filtrait rien au niveau 7. C'était inexact et cela sous-estimait le contrôle. Deux politiques WAF existent sur le profil et nous avions vérifié celle qui n'est pas rattachée au domaine public. Nous le corrigeons ici pour la même raison que nous avions publié la version originale — une affirmation erronée en notre faveur et une affirmation erronée à notre détriment sont toutes deux simplement fausses.*
• La haute disponibilité n'est pas activée sur la base de données, et nos RTO et RPO sont des objectifs internes plutôt que des engagements contractuels. Ce qui A évolué depuis la v1.0 : l'exercice de restauration est exécuté et documenté (une restauration complète en production mesurée à moins de 7 minutes), et les sauvegardes à long terme mensuelles sont désormais archivées sur un stockage géo-redondant par zone sous une politique d'immuabilité en écriture unique de 7 ans.
• Notre test de pénétration n'a pas été réalisé par un tiers accrédité CREST. Le test d'avril 2026 n'a retourné aucune constatation dans dix catégories OWASP ; il ne s'agissait pas d'un test indépendant accrédité, et nous le précisons là où un auditeur le cherchera.

Sur la différence entre conforme et certifié

Le dossier consacre un paragraphe à cette distinction, car elle est régulièrement brouillée sur ce marché. Annex 11 et 21 CFR Part 11 sont des exigences réglementaires, non des schémas de certification. Aucun organisme ne délivre de « certificat Annex 11 », et un fournisseur qui en propose un vend quelque chose qui n'existe pas. Ce qui peut réellement être attesté, c'est une mise en œuvre cartographiée clause par clause avec des artefacts justificatifs pour chaque ligne — ce que contient précisément ce dossier.

SOC 2 et ISO 27001 *sont* des schémas de certification. Nous ne les détenons pas. Nous ne nous décrivons donc pas comme certifiés, et les certifications de notre fournisseur d'infrastructure sont présentées comme les siennes plutôt que subrepticement comme les nôtres.

Tout ce qu'il contient a été vérifié, pas copié

Les documents de conformité se périment. Une région d'hébergement change, un écart est corrigé, un contrôle est renommé, et le document continue d'affirmer l'architecture de l'année passée avec la confiance de l'année en cours. Le nôtre avait commencé à le faire : un document interne du QMS décrivait encore un prestataire d'hébergement dont nous avions migré, et une page de notre propre site indiquait les mauvaises régions Azure.

Ainsi, chaque statut du dossier a été vérifié sur l'infrastructure de production en direct et le code source en direct le jour de la publication — les régions lues depuis l'abonnement, la politique de résidence lue depuis son affectation, la configuration de la périphérie lue depuis les en-têtes de réponse en direct, le comportement de la piste d'audit et de la signature lu depuis le code qui les implémente. Lorsque la vérification contredisait un document existant, la vérification l'a emporté. C'est également ainsi que nous avons découvert le problème du jeu de règles du pare-feu.

Le dossier est daté et comporte un engagement de révision : au moins tous les six mois, et réédité dès qu'un statut dans le tableau de certification ou la liste des points ouverts évolue.

Si vous êtes en charge de l'évaluation

Un document complémentaire existe. La Check-list de préparation aux audits GMP pour les opérations de cour est une auto-inspection en 101 points du périmètre de la cour — et son dernier domaine porte sur la qualification fournisseur de votre système de gestion de cour. Ce dossier est conçu pour répondre à ce domaine, que le fournisseur que vous évaluez soit nous ou non.

Si vous avez besoin d'un élément absent du dossier — l'ensemble complet du QMS sous NDA, des preuves de tests exécutés, un inventaire logiciel pour une version désignée, ou un CAIQ complété selon votre propre modèle — contactez-nous à admin@yardtwin.com. La liste des éléments disponibles sur demande figure au §18.