Un questionnaire fournisseur bien présenté peut masquer une faiblesse centrale d’un logiciel TPRM : que se passe-t-il quand une réponse est contestée, qu’un service devient critique ou qu’un sous-traitant change ? L’outil doit relier le fournisseur aux services qu’il soutient, aux preuves obtenues, aux décisions prises et au plan de sortie. Comparer le nombre de questions ou un score global ne suffit pas à vérifier cette chaîne.
Cette page propose une matrice d’achat et cinq tests de démonstration. Le logiciel de conformité multi-référentiels traite l’architecture globale ; la politique de sécurité fournisseurs organise les exigences. Ici, le choix porte sur la gestion opérationnelle du risque fournisseur. Le NIST SP 1305 invite à identifier les fournisseurs technologiques, à apprécier leur criticité et à communiquer des exigences adaptées. Il ne rend pas un logiciel TPRM obligatoire pour toutes les organisations françaises.
Définir le service acheté avant le fournisseur
Une entreprise peut acheter au même groupe un hébergement critique, une formation sans accès au SI et un support doté de privilèges. Une fiche fournisseur unique avec un score unique efface ces différences. Dans la démonstration, créez plusieurs relations service–entité–contrat. Indiquez qui consomme le service, quelles données et quels systèmes sont touchés, qui décide et quelles autres prestations dépendent du même fournisseur.
La criticité n’est pas le chiffre d’affaires du fournisseur ni son seul niveau de certification. Examinez l’effet d’une panne sur vos services, la difficulté de remplacement, la concentration, les accès techniques et les données manipulées. Le guide de criticité fournisseur peut aider à préparer ces critères. Le logiciel doit permettre une criticité différente pour deux services d’un même fournisseur et garder l’explication de chaque décision.
Préparez un échantillon de données fictives : une entité financière, une entité industrielle, deux services du même fournisseur, une dépendance commune et un contrat qui arrive à échéance. Cette complexité modeste suffit à révéler si le modèle réduit tout à une ligne « fournisseur » ou conserve les relations nécessaires.
Matrice de comparaison à remplir pendant la recette
Chaque critère doit être observé sur un cas plutôt que coché dans une réponse commerciale. Définissez avant la démonstration les critères indispensables et les réserves acceptables. Un fournisseur de logiciel peut répondre « oui » à une fonction présente dans une autre édition ou après développement ; seule la version et l’offre évaluées comptent pour la décision.
| Domaine | Question de démonstration | Résultat à conserver |
|---|---|---|
| Dépendances | Un fournisseur dessert-il plusieurs services/entités ? | Relations distinctes et impact d’une panne |
| Criticité | Peut-on expliquer la note par service ? | Faits, hypothèses et décideur |
| Exigences | Les demandes varient-elles selon le risque ? | Version, contrat et propriétaire |
| Preuves | Une pièce a-t-elle un périmètre et une date ? | Source, limites et jugement du réviseur |
| Exceptions | Un refus ou une absence reçoit-il une décision ? | Mesure temporaire, échéance, autorité |
| Remédiation | L’action est-elle vérifiée après exécution ? | Retest et résultat, pas ticket seul |
| Incidents | Qui est averti et quel service est touché ? | Chronologie et contacts pertinents |
| Sous-traitance | Un changement de chaîne est-il visible ? | Analyse et action contractuelle éventuelle |
| Sortie | Les données et dépendances sont-elles récupérables ? | Export et plan de transition |
La matrice n’est pas une promesse de couverture réglementaire. Les obligations applicables dépendent du secteur, du rôle, du service et du contrat. Évaluez séparément ce que le produit sait représenter et ce que vos équipes devront encore décider.
Test 1 : découvrir une dépendance qui change la priorité
Dans un exemple fictif, un prestataire de DNS ne traite aucune donnée personnelle sensible, mais sa panne interrompt deux services en ligne. Le logiciel doit montrer ces liens et faire remonter l’impact métier sans forcer l’équipe à qualifier le prestataire de « sous-traitant RGPD » pour le rendre important. Ajoutez une autre prestation de faible impact au même fournisseur : elle ne devrait pas recevoir automatiquement le niveau de contrôle du DNS.
Demandez comment le système apprend la dépendance : saisie manuelle, import de contrats, cartographie ou intégration. Qui vérifie l’information et que se passe-t-il si elle est contradictoire ? Une connexion automatique peut accélérer la découverte ; elle ne garantit pas que la relation est correcte. Le guide de cartographie SI aide à définir la source faisant autorité dans votre organisation.
Modifiez ensuite le fournisseur du DNS ou ajoutez une seconde voie. Le logiciel doit permettre de réévaluer l’impact, conserver l’ancienne décision et identifier les plans de continuité touchés. Si le score change sans montrer la cause, la direction risque d’accepter une conclusion incompréhensible.
Test 2 : demander une preuve dont la portée est limitée
Fournissez une attestation couvrant une filiale du fournisseur, mais pas le service acheté. Une plateforme utile ne devrait pas valider automatiquement tous les services associés au groupe. Le réviseur doit pouvoir indiquer ce que la pièce démontre, sa période, son périmètre, sa limite et la question encore ouverte. Un formulaire rempli par le fournisseur lui-même est un début d’information, pas nécessairement une preuve indépendante.
Ajoutez un rapport ancien et un compte rendu de test récent mais partiel. La date de téléchargement n’est pas la date de l’essai. Le guide de validité des preuves fournit la grille de portée et de changement. Dans la démo, vérifiez que le logiciel garde l’ancienne pièce comme trace historique et demande une nouvelle décision lorsque le service ou le périmètre change.
Le NIST SP 800-53A propose examen, entretien et test comme méthodes d’évaluation adaptables. Une plateforme peut organiser ces méthodes, mais la pertinence du rapport pour votre service reste une question humaine. Un score « 100 % preuves reçues » peut être exact administrativement et trompeur pour le risque.
Test 3 : gérer un refus et une exception
Le fournisseur refuse de partager un rapport complet pour des raisons de confidentialité. L’outil devrait permettre de demander un extrait, un entretien, une consultation sur place ou une autre assurance, selon le risque et le contrat. Il doit aussi permettre de constater que la réponse reste insuffisante. Une case « non applicable » utilisée pour fermer la demande sans justification supprime le désaccord du dossier.
Créez une exception provisoire : le service doit démarrer avant l’obtention d’une preuve de reprise. Nommez le décideur, le risque, la mesure temporaire, la date de réexamen et la condition de sortie. Si le produit ne distingue pas exception, refus et simple retard de réponse, le tableau de bord peut afficher une conformité artificielle. Le plan d’action d’audit montre comment vérifier la correction plutôt que fermer le ticket au moment où le fournisseur annonce avoir agi.
Testez l’escalade. Le responsable achats connaît le contrat ; le propriétaire métier connaît l’effet d’une panne ; le RSSI évalue la sécurité. Une plateforme ne décide pas lequel accepte le risque à leur place. Elle devrait rendre leur rôle visible et garder la version de la décision qu’ils ont examinée.
Test 4 : simuler un incident chez un sous-traitant
Le fournisseur annonce une indisponibilité touchant un service, sans savoir encore si des données personnelles sont affectées. Le logiciel doit relier l’incident aux services concernés, aux contacts d’astreinte et aux analyses nécessaires. Il ne doit pas transformer automatiquement toute panne en violation de données personnelles ou en incident DORA ; chaque régime possède ses propres conditions. La gestion des prestataires TIC sous DORA aide à délimiter le cas financier, sans rendre ces obligations applicables à tous les fournisseurs.
Conservez la chronologie : heure du message, informations reçues, questions posées, réponse du fournisseur, décision interne et mesures de continuité. Une réponse tardive peut révéler une clause inadaptée ou un mauvais contact. Demandez comment l’outil tient les versions d’une information qui évolue et qui peut envoyer une communication externe. Un compte rendu figé après le premier avis peut devenir trompeur.
Si le fournisseur s’appuie sur un sous-traitant dont la panne est la cause, testez la capacité à représenter la chaîne et les limites de visibilité. N’exigez pas que le logiciel connaisse magiquement tous les rangs de sous-traitance ; il doit montrer ce qui est connu, inconnu et à demander selon le droit contractuel disponible.
Test 5 : préparer la sortie avant la crise
Choisissez le service DNS fictif et annoncez une résiliation ou une défaillance. L’outil peut-il fournir contrats, propriétaires, dépendances, données à récupérer, accès à retirer et alternatives évaluées ? Si les informations sont dispersées dans des pièces jointes sans relation, le plan de sortie demandera une enquête d’urgence. La sortie est un critère d’achat du TPRM autant qu’un objet de suivi fournisseur.
Vérifiez l’export hors de la plateforme. Les identifiants du service et du fournisseur restent-ils stables ? Les décisions, preuves et exceptions sont-elles exportées avec leurs dates et leur portée ? Les liens vers des fichiers expirables restent-ils utilisables après la fin de l’abonnement ? Demandez les limites de volume et les frais éventuels dans l’offre réelle, plutôt que de supposer une réversibilité gratuite.
Un plan de sortie n’est pas toujours une bascule immédiate. Il peut prévoir continuité temporaire, coopération contractuelle, migration technique et suppression des accès. Le logiciel doit permettre d’attribuer ces étapes et de signaler les dépendances qui rendent une rupture rapide impossible. Une simple date de fin de contrat ne représente pas ce travail.
Comparer une plateforme dédiée et l’existant
Un registre simple et des réunions régulières peuvent suffire pour un petit nombre de fournisseurs et de services bien connus. Une plateforme peut devenir utile lorsque plusieurs entités partagent des fournisseurs, que les preuves changent souvent ou que les exceptions se perdent entre achats, sécurité et métiers. Ce choix dépend des volumes réels, des capacités internes et du risque. Ne fixez pas un seuil universel de « 50 fournisseurs » ou un retour sur investissement inventé.
Comparez aussi la qualité des données nécessaires. Une migration qui importe cent questionnaires mais ne relie pas les services aux fournisseurs peut augmenter le volume sans améliorer la décision. Le guide des logiciels d’audit RGPD traite une autre famille d’outils ; ne présumez pas qu’un module de questionnaires RGPD remplit toutes les fonctions TPRM décrites ici.
Demandez une proposition chiffrée sur le même périmètre à chaque candidat : entités, utilisateurs, fournisseurs, services, sous-traitants, connecteurs, stockage, export et assistance. Ajoutez le temps de nettoyage, de validation des relations et d’administration. Une réponse commerciale ne remplace pas le test des cinq scénarios dans la version que vous pourriez réellement acheter.
Vérifier qui entretient la donnée fournisseur
Pendant le pilote, faites changer l’adresse juridique du fournisseur, le propriétaire du service et le responsable de la relation achats. Demandez quelle source fait autorité pour chaque information. Le contrat peut relever des achats, les accès du responsable informatique et la criticité du métier. Un outil qui autorise tout le monde à modifier silencieusement une fiche commune peut créer des données contradictoires ; un outil qui verrouille tout derrière un administrateur unique risque de rendre les mises à jour trop lentes.
Testez une contestation : le métier juge un service critique alors que les achats l’ont classé ordinaire. L’application doit montrer les deux avis, nommer la personne habilitée à arbitrer et conserver la décision précédente. Un nouveau contrat ou un incident peut justifier de rouvrir cet arbitrage. Si la note change seule par un recalcul opaque, demandez quels champs l’ont provoqué et si le responsable a été averti. L’auditabilité d’une décision de risque dépend de cette histoire, pas de la précision apparente du chiffre final.
Vérifiez aussi la qualité des imports. Un fournisseur peut figurer sous plusieurs raisons sociales, avec des filiales, marques et identifiants de facturation différents. La déduplication ne doit pas fusionner des personnes morales distinctes ni propager une certification d’une filiale à toutes les autres. Conservez la provenance de chaque fiche et une règle de validation des rapprochements proposés. Une carte fournisseur inexacte rendra les cinq tests de recette artificiellement simples.
Examiner les droits du fournisseur dans la plateforme
Si le candidat propose un portail où les prestataires déposent leurs réponses, ouvrez une session avec un rôle de fournisseur fictif. Peut-il voir uniquement les demandes qui le concernent ? Une preuve chargée pour un client est-elle visible par un autre ? Qui peut inviter un collaborateur du fournisseur et révoquer son accès lorsque la relation se termine ? Ces vérifications portent sur la plateforme elle-même et doivent être incluses dans l’essai, pas supposées à partir d’une brochure de sécurité.
Le fournisseur peut avoir besoin de corriger une réponse ou de remplacer un rapport. Le système devrait conserver la version examinée par votre équipe et demander une nouvelle revue quand le contenu change. Un accès d’édition illimité après approbation rend la décision difficile à reconstituer. Demandez aussi comment les pièces sont restituées ou supprimées à la fin du contrat et quelles références demeurent dans votre dossier de décision. Le mécanisme doit concilier confidentialité du fournisseur et nécessité de justifier vos propres choix.
Décider sur les observations, pas sur un score unique
Pour chaque test, consignez le résultat, les manipulations effectuées, les limites et la condition de réussite. Certains critères peuvent être éliminatoires : impossibilité de distinguer deux services du même fournisseur, perte d’historique des décisions ou absence de sortie exploitable. D’autres peuvent être compensés par un processus interne acceptable. Fixez ces priorités avant la démonstration, afin de ne pas favoriser après coup l’interface la plus séduisante.
Le NIST SP 1305 en texte intégral insiste sur des exigences proportionnées à la criticité et sur la coordination des acteurs. Il autorise plusieurs formes de preuve et de suivi ; il ne consacre aucun éditeur. Une matrice d’achat bien remplie explique pourquoi une offre convient à vos services et quelles décisions humaines resteront nécessaires.
Le compte rendu final indique la version testée, les fonctionnalités incluses dans l’offre, les réserves à contractualiser et les travaux internes à mener. Un logiciel TPRM vaut par la qualité du cycle qu’il soutient : identifier une dépendance, demander une preuve pertinente, traiter une exception, vérifier une action et préparer une sortie. Un questionnaire reste un élément de ce cycle, pas sa conclusion.