Aide à la décision : choisir un prestataire IT selon des critères de risque, de conformité et de sécurité

Celui qui doit sélectionner un prestataire informatique ne décide pas seulement des taux journaliers et de la disponibilité, mais aussi d’une extension de sa surface d’attaque, des obligations réglementaires de preuve et de la vitesse à laquelle il peut retrouver sa capacité d’action en cas d’incident. Dans de nombreuses entreprises, les prestataires deviennent de fait des co‑exploitants : ils administrent des systèmes, transfèrent des données, configurent des mécanismes de sécurité et influent sur les processus opérationnels. C’est précisément pour cela qu’un « bon ressenti lors du pitch » ne suffit pas.

Cet article est destiné à aider la direction informatique, la sécurité de l’information (ISMS), la protection des données, la conformité et la direction générale dans leur prise de décision. Il présente une méthode opérationnelle pour évaluer les prestataires sur la base des risques : quels éléments de preuve sont pertinents, quels contrôles sont indispensables, comment établir la gouvernance et les responsabilités, et comment éviter les pièges typiques (sous‑traitants, accès aux logs, sortie, chaînes de preuve). L’objectif est une décision de sélection qui tienne lors d’un audit et qui n’entraîne pas de surprises en exploitation.

1) Point de départ : que signifie concrètement le « risque » pour un prestataire informatique ?

Dans le contexte des fournisseurs, le risque n’est pas abstrait mais très concret : il s’agit de la combinaison entre la probabilité d’occurrence et l’impact sur la confidentialité, l’intégrité et la disponibilité (triade CIA). À cela s’ajoute la capacité de preuve : pouvez-vous démontrer que des contrôles existent et sont efficaces ?

Pour l’évaluation, une séparation claire en quatre domaines de risque est utile :

• Risque lié aux données : quelles données le prestataire traite‑il (données à caractère personnel, confidentielles, secrets commerciaux) ? Où sont‑elles stockées, comment sont‑elles chiffrées, qui y a accès ?
• Risque d’accès et d’exploitation : le prestataire obtient‑il un accès administrateur, un accès shell, un accès VPN ou seulement un accès sur tickets ? Existe‑t‑il des accès d’urgence ? Les modifications sont‑elles réalisées via une gestion des changements ?
• Risque lié à la chaîne d’approvisionnement : sous‑traitants (p. ex. fournisseurs cloud, chaînes de support), changements de site, dépendances, outils propriétaires, obstacles à la sortie.
• Risque de conformité et d’audit : DSGVO, règles sectorielles, politiques internes, conservation, journalisation, obligations de preuve, droits d’audit.

Une décision de sélection fiable exige que vous décriviez d’abord avec précision l’utilisation prévue du prestataire : systèmes, classes de données, privilèges, fenêtres d’exploitation, RTO/RPO (temps de reprise/point de reprise) et interfaces organisationnelles. Sans cette délimitation, toute évaluation sera soit trop souple (« tout est important »), soit trop stricte (« tout est interdit »).

2) Classification des risques avant le screening : Tiering plutôt que le ressenti

En pratique, un Tiering (classification en niveaux de criticité) s’avère efficace : il pilote l’effort de Due Diligence et les clauses contractuelles. Cela évite de déployer la machine d’audit complète pour chaque petit contrat de support — tout en garantissant que des partenaires critiques ne passent pas entre les mailles du filet.

Proposition pour 4 tiers (ajustable)

• Tier 1 – Critique : accès Admin/Root, réseaux proches de la production, traitement de données sensibles, exploitation de processus critiques, conséquences d’arrêt significatives.
• Tier 2 – Élevé : accès à des systèmes importants ou à de grands volumes de données, mais avec des RESTrictions (p. ex. uniquement via Jump-Host, périmètre strictement séparé).
• Tier 3 – Moyen : accès limité, principalement conseil/travaux projet, traitement de données RESTreint.
• Tier 4 – Faible : aucun ou minimal traitement de données, aucun accès aux systèmes productifs (p. ex. formation).

Un Tiering ne devrait pas reposer uniquement sur « Cloud vs. On-Prem », mais sur les privilèges, les classes de données et la responsabilité d’exploitation. Un administrateur externe sur un réseau interne est souvent plus risqué qu’un service SaaS avec un modèle de locataires propre et des preuves claires.

3) Question centrale dans le processus de sélection : quel modèle d’exploitation prenez-vous en charge vous-même — et que déléguez-vous réellement ?

Beaucoup de conflits ultérieurs proviennent d’attentes floues : « Managed » ne signifie pas automatiquement 24/7, pas automatiquement l’application des correctifs, pas automatiquement des tests de RESTauration de sauvegarde. C’est pourquoi le modèle d’exploitation doit être décrit en langage opérationnel avant la signature du contrat.

Délimitation pratique : RACI et artefacts d’exploitation

RACI attribue des rôles : Responsible (exécutant), Accountable (responsable ultime), Consulted (consulté), Informed (informé). Pour les audits, il est particulièrement important que « Accountable » RESTe sans ambiguïté, même si un pRESTataire agit de manière opérationnelle.

Artefacts que vous devriez exiger de manière contraignante pour les pRESTataires critiques :

• Manuel d’exploitation / runbooks (routine et gestion des incidents)
• Processus de changement incluant les règles d’approbation et le rollback
• Voies de supervision et d’alerte (y compris astreintes)
• Concept de sauvegarde et de RESTauration (y compris preuves de tests)
• Gestion des correctifs et des vulnérabilités (cycles, exceptions, autorisations de risque)
• Gestion des incidents incluant la préservation des preuves (evidence) et la matrice de communication

4) Conformité et preuves : quels documents sont réellement utiles ?

On confond souvent conformité et « papier ». L’essentiel est de savoir si les preuves sont vérifiables et pertinentes par rapport au périmètre. Un certificat ISO-27001 peut avoir de la valeur — mais sans vérification du périmètre, il en dit peu. Un rapport SOC-2 (Type II) peut être très utile — mais seulement si les contrôles correspondent à vos risques et que les exceptions (exceptions) sont comprises et traitées.

Preuves qui ont réellement de la substance en pratique

• Preuves ISMS : ISO 27001 (périmètre, Statement of Applicability), politiques internes, traitement des risques.
• SOC 2 Type II : période, Trust Services Criteria vérifiés, constats/exceptions, sous-traitants / organisations de subservice.
• Preuves de tests d’intrusion / gestion des vulnérabilités : fréquence, périmètre, traitement des constats (sans que vous ayez nécessairement besoin des rapports détaillés).
• Documents de protection des données : AVV (Auftragsverarbeitung), TOMs (mesures techniques et organisationnelles), liste des sous-processeurs, concept de suppression et de RESTitution.

Important : « Nous respectons la DSGVO » n’est pas une déclaration. Pour la DSGVO, vous avez besoin de blocs concrets : AVV, finalité, catégories de personnes concernées, types de données, délais de suppression, mesures techniques, transferts internationaux (p. ex. clauses contractuelles types) et une gestion solide des sous‑traitants.

5) Critères de sécurité pour la sélection : contrôles qui comptent en exploitation

Pour la décision de sélection, formulez les critères de sécurité de façon à pouvoir les rendre opérationnels ensuite. Au lieu de « haute sécurité », exigez des exigences vérifiables. Ci‑après les familles de contrôles qui se révèlent régulièrement déterminantes dans les relations avec des prestataires.

Identités et accès privilégiés (IAM/PAM)

IAM (Identity and Access Management) gère les identités, les rôles et les autorisations. PAM (Privileged Access Management) contrôle les accès administrateur particulièrement puissants, idéalement limités dans le temps et traçables.

• Utilisateurs individuels au lieu de comptes partagés
• MFA (authentification multifacteur) obligatoire
• Just-in-Time/Just-Enough-Access, autant que possible
• Accès via Jump-Hosts/Bastion, pas de connexions admin directes depuis Internet
• Enregistrement des sessions ou au moins journaux d’audit détaillés pour les actions privilégiées

Question d’audit : Pouvez‑vous, en cas d’incident, prouver qui quand quoi a fait, et pouvez‑vous révoquer les accès en quelques minutes ?

Séparation réseau et isolation des locataires

Pour les services managés, la segmentation est cruciale : réseaux séparés pour management, production, sauvegarde, journalisation ; règles de pare‑feu claires ; et un règlement documenté pour les exceptions. L’isolation des locataires est centrale chez les fournisseurs SaaS : séparation logique (Tenant-Isolation), chiffrement et protection contre les fuites de données dues à des erreurs de configuration.

Gestion des vulnérabilités et des correctifs

Pour la sélection et le contrat, le « cycle de patch » importe moins que la capacité à maîtriser les risques : comment se fait la priorisation (critique/élevé/moyen), comment les exceptions sont‑elles documentées, comment se fait la compensation (p. ex. règles WAF, isolation), et à quelle vitesse des hotfixes peuvent‑ils être déployés ?

Une preuve simple mais efficace est une exportation régulière du processus ticket/vulnerability (anonymisée), montrant : réception, évaluation, délai, mise en œuvre, revue.

Journalisation, monitoring, capacité forensique

C’est là que se joue la préparation à l’audit : sans logs fiables (horodatage, protection d’intégrité, conservation), les incidents restent une question d’opinion. C’est particulièrement délicat lorsque les logs sont chez le prestataire alors que vous, en tant que client, assumez l’obligation de preuve.

• Sources de logs définies (Auth, actions admin, modifications système, accès API)
• Dépôt central avec concept d’accès (principe du moindre privilège)
• Durées de conservation conformes à la réglementation et aux politiques internes
• Intégrité (protection contre la manipulation) et synchronisation temporelle (NTP)

6) Protection des données et souveraineté des données : AVV n’est que le début

La protection des données est souvent réduite à l’AVV lors du choix d’un pRESTataire. C’est risqué, car les questions critiques se situent dans la mise en œuvre technique : où les données sont-elles traitées, comment sont-elles chiffrées, comment s’effectue la suppression, et comment la RESTitution des données est-elle réalisée lors de l’exit ?

Exigences concrètes que vous devriez documenter

• Localisation des données : régions/centres de données, transferts internationaux, bases juridiques.
• Chiffrement : en transit (TLS) et au repos ; gestion des clés (KMS), accès aux clés.
• Sauvegardes : contiennent-elles des données à caractère personnel ? Comment les sauvegardes sont-elles supprimées ? Quelle rétention s’applique ?
• Demandes des personnes concernées : assistance pour l’accès/la suppression/l’export, délais et processus.
• Modèle de rôles : qui est responsable, qui est sous-traitant, qui est sous‑traitant ultérieur ?

Si vous avez des exigences strictes (p. ex. contrôle des clés par vos soins, « Bring Your Own Key »), ces exigences doivent figurer avant la sélection dans les critères obligatoires. À posteriori, ces points sont souvent coûteux ou techniquement irréalisables.

7) Sous-traitants et chaîne d’approvisionnement : l’angle mort de la gestion des fournisseurs

Beaucoup de risques ne naissent pas chez le partenaire choisi, mais dans la chaîne : hébergement cloud, NOC 24/7, équipes de développement externes, support dans d’autres juridictions. Les sous-traitants ne sont pas intrinsèquement problématiques — mais ils doivent être transparents, contrôlables et couverts contractuellement.

Ce que vous devriez exiger

• Liste actuelle des sous‑traitants avec parts de service et accès aux données
• Processus de changement : information préalable et droits d’opposition/de résiliation en cas de modifications critiques
• Clauses de « flow-down » : les exigences de sécurité et de protection des données s’appliquent dans la chaîne
• Droits d’accès aux preuves pertinentes (p. ex. rapports SOC de l’organisation du sous‑traitant)

8) Logique contractuelle et SLA : les exigences de sécurité doivent devenir mesurables

Les contrats échouent rarement en raison d’une clause manquante, mais plutôt à cause d’attentes non mesurables. Les SLA (Service Level Agreements) décrivent des objectifs de service (p. ex. disponibilité, temps de réponse). Les OLA (Operational Level Agreements) sont des accords internes/opérationnels entre équipes ou entre unités du pRESTataire, qui rendent les SLA réalisables.

Éléments typiques de SLA que vous devriez préciser

• Classification des incidents : définitions P1/P2/P3 basées sur l’impact business
• Temps de réaction et de rétablissement : pas seulement « Response », mais « RESTore »
• Fenêtres de changement : changements standard vs. changements d’urgence, obligation de documentation
• SLA de sécurité : délais de correction des vulnérabilités critiques, cycles de correctifs, règles d’exception
• Reporting : rapports mensuels de service avec indicateurs définis et analyse des écarts

Important du point de vue de l’audit : si vous consignez des contrôles de sécurité dans le contrat, vous avez aussi besoin d’une routine de mesure et de preuve. Sinon un fossé se crée entre le contrat et la réalité.

9) Perspective d’audit : Ce que les vérificateurs veulent typiquement voir

Les audits examinent rarement des détails techniques isolés, mais la contrôlabilité : existe-t-il une procédure, les décisions sont-elles documentées, les responsabilités sont-elles claires, et les contrôles sont-ils efficaces. Pour les relations avec des pRESTataires, de nombreux examens se résument à trois questions :

• Les risques ont-ils été évalués avant la mise en service ? (Due Diligence, Tiering, autorisations)
• Les contrôles sont-ils opérationnels et ancrés contractuellement ? (SLA, exigences de sécurité, protection des données, sous-traitants)
• Pouvez-vous démontrer l’efficacité ? (rapports, logs, tests, procès-verbaux de revue)

Être auditable ne signifie pas « accablé de documents ». Cela signifie : prendre des décisions traçables, documenter de façon concise, stocker les preuves de manière centralisée et effectuer des revues régulières.

10) Checklist pratique : Due-Diligence‑Questions, die in der Auswahl wirklich helfen

La liste suivante est conçue comme un noyau pragmatique. Elle ne remplace pas une analyse de risque individuelle, mais couvre les critères de décision typiques qui seront pertinents ultérieurement en exploitation et lors d’un audit.

A) Périmètre et accès

• Quels systèmes/environnements sont dans le périmètre (Prod/Stage/Dev) ?
• Quels types d’accès (VPN, Jump-Host, API, Ticket-only) sont requis ?
• Comment les accès privilégiés sont-ils accordés, consignés et retirés ?

B) Contrôles de sécurité

• Quelles normes minimales s’appliquent (MFA, politique de mots de passe, hardening, EDR/AV) ?
• Comment fonctionne le Patch-/Vulnerability-Management, incl. priorisation et exceptions ?
• Comment est mis en œuvre le logging, qui y a accès, quelle rétention s’applique ?

C) Protection des données et gestion des données

• AVV/TOMs : sont-ils à jour et adaptés au processus réel ?
• Localisation des données, sous-traitants, transferts internationaux : bien décrits ?
• Suppression, RESTitution et rétention des sauvegardes : réalisables opérationnellement ?

D) Exploitation, résilience, gestion des incidents

• Monitoring et astreinte : horaires, voies d’escalade, canaux de communication ?
• Sauvegarde/RESTore : les RESTaurations sont-elles testées et documentées ?
• BCM/DR : y a-t-il des tests, et quels ont été les derniers résultats ?

E) Gouvernance et preuves

• Quelles preuves (ISO/SOC) sont disponibles et quel périmètre couvrent-elles ?
• Comment les changements, incidents et revues sont-ils documentés ?
• Existe-t-il un droit d’audit, et comment est-il mis en œuvre concrètement (p.ex. audit à distance, consultation de rapports) ?

11) Approche par scorecard : rendre la décision transparente (sans fausse précision)

Une scorecard aide à comparer plusieurs fournisseurs et à justifier les décisions auprès de la direction, de l’audit ou de la protection des données. Important : pas de fausse précision. Utilisez peu de critères, une pondération claire et documentez les écarts avec des mesures compensatoires.

Proposition de pondération (exemple)

• 30% Sécurité & contrôles d’accès
• 25% Exploitation & résilience (RTO/RPO, runbooks, astreinte)
• 20% Conformité & preuves (ISO/SOC/AVV, capacité d’audit)
• 15% Chaîne d’approvisionnement & contrôle des sous-traitants
• 10% Facteurs commerciaux (modèle de coûts, transparence, flexibilité)

Pour les prestataires de niveau 1, il devrait exister des critères impératifs qui ne peuvent pas être « pondérés » (p. ex. MFA, comptes individuels, AVV pour les données à caractère personnel, règle de sortie, journalisation). Si un critère impératif n’est pas respecté, le fournisseur est soit exclu, soit une dérogation de risque formellement approuvée avec compensation est nécessaire.

12) Plan de sortie et de gestion des urgences : critère de sélection, pas réflexion de clôture

Le concept d’Exit évoque la fin d’un contrat, mais c’est un levier de sécurité et d’exploitation : que se passe-t-il en cas d’insolvabilité, d’incident majeur, de litige, d’arrêt réglementaire ou de changement stratégique ? Sans plan de sortie, le risque d’enfermement augmente, et en cas d’urgence il manque le temps, les données et le savoir-faire pour une remise propre.

Éléments à inclure dans la sélection et le contrat

• Retour des données : formats, exhaustivité, délais, responsabilités
• Confirmation de suppression : y compris sauvegardes/copies d’archives (dans la mesure du possible techniquement, décrit de façon transparente)
• Remise de la documentation : Runbooks, architecture, configurations, inventaire des clés/certificats
• Support de transition : heures/quotas définis, tâches prioritaires, accès pour le successeur
• Exit d’urgence : résiliation exceptionnelle, accès aux systèmes/Logs, gel des changements

Du point de vue de l’exploitation, il est particulièrement important que vous ne receviez pas seulement des « données », mais aussi la capacité opérationnelle : configurations, modèles d’accès, configurations de monitoring et procédures de restauration.

13) Blocs sources pratiques : modèles de politiques et commandes de vérification

Les exemples suivants sont volontairement génériques et doivent être adaptés à votre environnement. Vous pouvez les utiliser comme point de départ pour des politiques internes, des exigences fournisseurs ou des contrôles d’audit.

Modèle de politique : exigences minimales pour les accès des prestataires

POLICY: Accès des tiers aux systèmes informatiques (exigences minimales)

1. Identités
- Uniquement des comptes utilisateur individuels, pas de comptes partagés.
- MFA obligatoire pour tous les accès externes.
- Droits basés sur les rôles (Least Privilege), droits administrateur limités dans le temps (Just-in-Time).

2. Voies d'accès
- Accès administratifs uniquement via des Jump-Hosts/Bastion définis ou une solution PAM.
- Pas d'accès administratif direct depuis Internet.
- Accès uniquement depuis des réseaux/sources autorisés (Allowlist), dans la mesure du possible.

3. Journalisation
- Authentification, actions privilégiées et modifications de configuration sont enregistrées de façon centralisée.
- Les logs sont protégés contre la manipulation et conservés conformément aux règles de rétention.

4. Onboarding/Offboarding
- Processus d'approbation avant mise en place, incl. ticket et propriétaire.
- Déprovisionnement dans un délai défini après changement de rôle/fin de projet.

5. Exceptions
- Exceptions uniquement avec évaluation de risque documentée, date d'expiration et mesures compensatoires.

Commandes de vérification (exemples) : traçabilité des accès administratifs sous Linux

Pour de nombreux environnements, il est important que les actions privilégiées soient traçables. Les contrôles suivants aident à vérifier des bases typiques (auditd/journal/sudo). Ils ne constituent pas un audit de sécurité complet, mais un contrôle de réalité rapide lors de l’onboarding ou d’une revue.

# Prüfen, ob sudo-Aktionen geloggt werden (Beispielpfade je nach Distribution)
sudo grep -R "^Defaults" /etc/sudoers /etc/sudoers.d 2>/dev/null | head

# Letzte sudo-Ereignisse (wenn über journald erfasst)
sudo journalctl -u sudo --since "7 days ago" 2>/dev/null | tail -n 50

# Prüfen, ob auditd aktiv ist
sudo systemctl status auditd --no-pager

# Audit-Regeln anzeigen (falls auditd genutzt wird)
sudo auditctl -l 2>/dev/null | head -n 50

Pour l’évaluation d’un prestataire, il importe moins qu’un outil particulier soit utilisé que de savoir si votre objectif est atteint : traces d’audit inaltérables, centralisées et exploitables pour les actions pertinentes.

14) Estimer de manière réaliste coûts et efforts : la sécurité n’est pas gratuite, l’incertitude coûte plus cher

Un choix basé sur le risque permet d’économiser s’il évite d’acheter « pas cher » au mauvais endroit. Postes de coûts typiques sous-estimés dans les business cases :

• Coûts de transaction : onboarding, due diligence, revue contractuelle, intégration d’outils
• Coûts de contrôle : revues, rapports, audits, tests d’intrusion, recertification des accès
• Coûts d’incident : forensique, arrêt, communication aux clients, notifications réglementaires
• Coûts de lock-in : projet de sortie, migration des données, transfert de connaissances

Une approche pragmatique : traitez les fournisseurs Tier-1 comme des systèmes internes critiques. Cela ne signifie pas « tout faire soi‑même », mais assurer la maîtrisabilité : rôles clairs, indicateurs clairs, preuves claires.

15) Gouvernance au quotidien : qui décide quoi – et qui porte quelle responsabilité ?

La gouvernance des fournisseurs ne fonctionne que si elle est appliquée au quotidien. Cela implique des rituels fixes et des responsabilités clairement définies :

• Service Owner côté client : responsable fonctionnel/opérationnel, évalue les rapports, pilote le backlog
• Security/Compliance : définit les contrôles obligatoires, vérifie les écarts, approuve les exceptions
• Datenschutz : évalue les flux de données, les contrats de sous-traitance/mesures techniques et organisationnelles (AVV/TOMs), les transferts, les concepts de suppression
• Provider Manager (ou Einkauf/Legal) : gestion contractuelle et des escalades
• IT-Betrieb : intègre le monitoring, le logging, les sauvegardes, les changements, les processus d’astreinte

Les Service Reviews trimestriels (SLA, incidents, changements, constats de sécurité) et un Re-Assessment annuel pour Tier-1/2 se sont révélés efficaces. Pas comme formalité, mais comme moment pour poser des questions difficiles : le périmètre, les sous-traitants, les classes de données ou les schémas d’accès ont-ils changé ?

Fazit: IT-Dienstleister auswählen heißt steuerbare Risiken einkaufen

Une bonne décision de sélection repose sur un principe simple : plus l’accès est large et plus les données ou la responsabilité opérationnelle sont critiques, plus les preuves, contrôles et règles de sortie doivent être stricts. Si vous combinez proprement le tiering, la scorecard et les critères obligatoires, vous éviterez deux excès : des exigences disproportionnées pour des fournisseurs non critiques et des lacunes dangereuses chez des partenaires critiques.

Appuyez-vous sur des critères vérifiables (IAM/PAM, logging, processus de patch, gouvernance des sous-traitants), ancrez-les contractuellement de manière mesurable (SLA/Security SLAs) et planifiez la sortie ainsi que les transferts d’urgence dès le départ. Ainsi, la gestion des prestataires devient moins une question d’« intuition » et davantage une discipline exploitable en audit et opérationnelle.

Pour ce sujet, la gestion des risques liés aux prestataires tiers et la gestion des fournisseurs IT sont également importantes. L’article situe ces aspects de manière claire et montre ce qui importe au quotidien.