Bus factor : votre infrastructure cloud repose sur une seule personne

Dans une scale-up sans équipe d'infrastructure dédiée, la plateforme cloud a pu être construite par une seule personne : celle qui a ouvert le compte AWS, écrit le code d'infrastructure, branché les sauvegardes et reçoit les e-mails du fournisseur. Tant qu'elle est là, tout fonctionne. Le jour où elle est en congé, malade ou partie, l'entreprise découvre ce qu'elle seule savait faire.

Cet article s'adresse au CEO ou au CTO qui veut mesurer cette dépendance sans chercher de coupable. Il propose des signes factuels, une liste de vingt points vérifiables adossés à la documentation officielle d'AWS, un protocole pour tester la couverture avant l'absence de la personne clé, puis un plan sur 30 jours.

Bus factor : une mesure de l'organisation, pas un reproche

Ce que mesure le bus factor

La recherche en génie logiciel donne au terme une définition stable. Une étude de 2026 consacrée au calcul du bus factor (source 1) le présente comme une mesure du risque d'un projet au regard de la disponibilité des personnes, défini de façon informelle comme le nombre de personnes dont l'indisponibilité soudaine provoquerait l'arrêt du projet ou des retards sévères. Une étude présentée à la conférence ICSE 2022 (International Conference on Software Engineering, source 2) le décrit comme la mesure de la résistance d'un projet au départ soudain d'ingénieurs : le nombre minimal d'ingénieurs dont la disparition suffirait à bloquer le projet.

Les méthodes de calcul diffèrent. Le projet CHAOSS (Community Health Analytics in Open Source Software), hébergé par la Linux Foundation, retient pour les projets open source le plus petit nombre de contributeurs responsables de la moitié des contributions ; il nomme désormais cette métrique Contributor Absence Factor. L'étude de 2026 distingue deux lectures : la redondance (le plus grand groupe de personnes qui peuvent partir sans compromettre l'avancement du projet) et la criticité (le plus petit groupe dont le départ suffit à bloquer le projet). Toutes deux reposent sur un seuil arbitraire de tâches laissées sans personne pour les porter, et les auteurs démontrent que leur calcul exact est un problème difficile (NP-difficile, au sens de la théorie de la complexité).

Pourquoi compter en gestes, pas en commits

Pour une infrastructure cloud, compter les contributions dans Git dit qui a modifié la plateforme, pas qui saurait la remettre en marche. Nous proposons une unité plus utile au dirigeant : le geste critique. Un geste critique est une action dont l'impossibilité, un jour donné, arrête la production ou bloque une décision. Par exemple : se connecter au compte AWS de production avec des droits d'administration, déployer une correction, restaurer une base de données, renouveler un certificat ou un nom de domaine, révoquer l'accès d'une personne qui part, répondre à un e-mail de sécurité d'AWS.

Pour chaque geste, la question est simple : combien de personnes l'ont déjà exécuté seules, récemment, avec la procédure écrite comme seule aide ? Le bus factor de la plateforme ne peut pas dépasser le plus petit de ces nombres. S'il vaut un pour la restauration de la base principale, il vaut un pour toute la plateforme, quelle que soit la taille de l'équipe produit.

Des signes factuels, sans faute à chercher

La personne clé n'a, dans ce schéma, rien fait de mal : elle a construit vite ce dont l'entreprise avait besoin. Le risque est dans l'organisation qui n'a pas prévu de relais. Les signes suivants se constatent sans entretien ni jugement, dans les outils :

• l'historique du dépôt d'infrastructure, ou les journaux AWS CloudTrail, montrent une seule personne derrière les changements et les connexions à privilèges ;
• l'adresse e-mail de l'utilisateur racine est une boîte personnelle, ou le dispositif MFA du compte racine est installé sur un seul téléphone ;
• les e-mails d'AWS (facturation, fin de support d'une version, avis de sécurité) arrivent chez une seule personne ;
• les abonnements à des outils tiers (nom de domaine, supervision, registre d'images) sont réglés par une carte ou rattachés à un compte personnel ;
• personne d'autre n'a jamais restauré une sauvegarde, ou la dernière restauration n'a laissé aucune trace écrite ;
• les congés de cette personne se placent en fonction des livraisons, ou elle reste joignable pendant ses vacances « au cas où ».

Un seul de ces signes ne prouve rien. Plusieurs signes réunis sur un même périmètre suffisent à justifier les vérifications qui suivent.

Vingt points à vérifier, en quatre familles

Chaque point se vérifie par une preuve observable : un réglage, un fichier daté, un compte rendu. Les points qui citent AWS reprennent sa documentation, listée en fin d'article.

Accès : qui peut entrer, et par où

Les points 1 à 4 et 19 supposent un compte AWS doté d'un utilisateur racine, celui de l'inscription classique ; le point 16 vaut aussi pour un compte dont les fonctions avancées ont été activées. Le cas des comptes créés avec la nouvelle expérience d'inscription est précisé en fin d'article.

1. L'utilisateur racine utilise une adresse de groupe. AWS recommande une adresse gérée par l'entreprise qui transmet les messages directement à un groupe d'utilisateurs, pour que l'entreprise réponde même si une personne est en congé, malade ou a quitté l'entreprise, et de ne pas utiliser cette adresse à d'autres fins. Preuve : l'adresse affichée dans les paramètres du compte et la liste des membres du groupe.
2. Plusieurs dispositifs MFA sont enregistrés sur l'utilisateur racine. Tous les types de comptes AWS exigent désormais le MFA pour leur utilisateur racine, et AWS en impose l'enregistrement dans les 14 jours qui suivent une première tentative de connexion à la console s'il n'est pas déjà activé ; la question principale n'est donc plus de savoir si le MFA existe, mais qui le détient. L'utilisateur racine accepte jusqu'à huit dispositifs MFA, et AWS recommande fortement d'en activer plusieurs. Preuve : la liste des dispositifs et, pour chacun, son détenteur ou son lieu de rangement.
3. Le mot de passe racine est rangé hors du compte qu'il protège. AWS déconseille de stocker ce mot de passe dans un outil qui dépend de services AWS hébergés dans le même compte, recommande d'envisager une autorisation par deux personnes ou plus pour accéder à l'emplacement de stockage, et de journaliser cet accès. Preuve : l'emplacement du coffre, sa règle d'accès et son journal.
4. Les canaux de récupération sont tenus par deux groupes distincts. La boîte e-mail et le numéro de téléphone du compte permettent tous deux de récupérer l'accès racine. AWS recommande qu'aucune personne n'ait accès aux deux, et de tenir le numéro à jour. Preuve : qui gère la boîte, qui gère la ligne, date de la dernière vérification du numéro.
5. Les accès quotidiens sont fédérés et au moins deux personnes peuvent administrer. AWS demande que les utilisateurs humains accèdent aux comptes par une fédération avec des identifiants temporaires, et recommande AWS IAM Identity Center pour gérer centralement les accès à plusieurs comptes (IAM, Identity and Access Management, désigne chez AWS la gestion des identités et des accès). Notre recommandation : au moins deux personnes disposent, chacune avec son identité nominative, des droits d'administration nécessaires aux gestes critiques. Preuve : la liste des affectations d'accès aux comptes de production.
6. Un accès d'urgence existe, indépendant du fournisseur d'identité habituel, et il a été testé. La bonne pratique SEC03-BP03 du cadre AWS Well-Architected cite comme anti-modèle un processus d'urgence qui dépend des mêmes systèmes, par exemple le fournisseur d'identité centralisé, que l'accès normal. Elle demande de créer à l'avance les ressources de l'accès d'urgence, de journaliser chaque tentative réussie ou échouée, d'alerter sur tout usage hors urgence et de tester le processus périodiquement. Preuve : la procédure, le compte qui la porte, la date du dernier test.

Pour une organisation AWS Organizations à plusieurs comptes, AWS recommande en outre de retirer les identifiants racine des comptes membres et de centraliser l'accès racine. Le compte de gestion reste alors celui dont l'utilisateur racine doit satisfaire les points 1 à 4.

Savoir : ce qui doit exister sans la personne clé

7. Un inventaire tenu à jour. Comptes et environnements, régions utilisées, services managés, noms de domaine, certificats, fournisseurs tiers, abonnements et leur titulaire, qui doit être l'entreprise et non une personne. Preuve : un fichier daté dans le dépôt de l'entreprise.
8. Un schéma d'architecture daté et versionné. Un schéma décrit en texte peut se relire dans une revue de code, comme le reste du dépôt. Preuve : la date du dernier changement et le nom de son dernier relecteur.
9. Des procédures écrites pour chaque geste critique, dans le dépôt de l'entreprise. Une procédure d'exploitation (runbook) décrit le contexte, les étapes, la vérification du résultat et le retour arrière. Les travaux DORA (DevOps Research and Assessment), menés par Google Cloud et à ne pas confondre avec le règlement européen sur la résilience opérationnelle numérique, évaluent la qualité de la documentation par des critères comme la clarté, la facilité à la trouver et la fiabilité, et rappellent qu'elle demande un travail actif de création et d'entretien. Ces travaux relient la qualité de la documentation à la performance. Preuve : une procédure par geste, avec sa date de dernière exécution.
10. Une infrastructure décrite en code, sans dérive connue. Le code d'infrastructure vit dans un dépôt dont l'entreprise est propriétaire, et une exécution récente du plan n'annonce aucun changement inattendu. Si une partie a été créée à la main, la démarche est détaillée dans Terraform import : reprendre une infrastructure AWS existante sans la recréer. Preuve : la sortie datée du dernier plan.
11. Les décisions et les exceptions sont écrites. Sans trace écrite, les raisons d'un choix technique ou d'une exception partent avec la personne qui les connaît. Preuve : un registre court de décisions, chacune datée et signée.

Continuité : une question chacun, puis une preuve

12. Le RTO tient en une question. Pour AWS, le RTO (Recovery Time Objective, objectif de temps de reprise) est le plus long délai tolérable entre l'arrêt d'un service et son retour. La question à poser à la direction : « Combien de temps pouvons-nous rester sans ce service avant un impact inacceptable pour l'entreprise ? » Preuve : une réponse chiffrée, datée, signée par une personne de la direction.
13. Le RPO tient en une question. Le RPO (Recovery Point Objective, objectif de point de reprise) est, toujours selon AWS, le plus long intervalle tolérable depuis le dernier point de récupération des données. La question : « Combien d'heures de données récentes pouvons-nous perdre sans dommage inacceptable ? » Preuve : la même signature. AWS range parmi les anti-modèles des objectifs arbitraires, ou irréalistes comme une perte nulle. La traduction de ces objectifs en plan complet est détaillée dans Plan de reprise d'activité dans le cloud : un PRA n'est pas une politique de sauvegarde.
14. Une restauration a été testée, et par quelqu'un d'autre que la personne clé. La bonne pratique REL09-BP04 d'AWS demande de restaurer périodiquement les sauvegardes pour vérifier qu'elles respectent le RTO et le RPO. Ses anti-modèles décrivent exactement une plateforme à bus factor de un : supposer qu'une sauvegarde existe, restaurer sans interroger les données, restaurer sans procédure écrite. Preuve : un compte rendu daté avec l'exécutant, l'horodatage de la donnée la plus récente retrouvée et la durée mesurée.
15. La restauration ne dépend d'aucun accès personnel. Les sauvegardes, les clés de chiffrement, le code d'infrastructure et les secrets nécessaires sont accessibles par les identités prévues au point 5 ou par l'accès d'urgence du point 6. Preuve : le compte rendu du point 14 ne mentionne aucune aide de la personne clé.

Exploitation : ce qui arrive, à qui, et ce qu'on en fait

16. Les contacts alternatifs AWS sont des listes de l'entreprise. Un compte AWS accepte trois contacts alternatifs (facturation, opérations, sécurité) en plus de l'adresse de l'utilisateur racine. AWS précise qu'un contact alternatif peut être une liste de diffusion plutôt qu'une personne, et recommande, pour un compte d'entreprise, une adresse et un téléphone de l'entreprise. Preuve : les trois contacts renseignés.
17. Les événements AWS Health arrivent dans une file traitée. AWS Health envoie, au nom des autres services, des événements sur les changements planifiés (fins de support de versions, mises à niveau automatiques, maintenances) et des notifications de compte. Ces événements portent un statut d'action : ACTION_REQUIRED, ACTION_MAY_BE_REQUIRED ou INFORMATIONAL ; ceux qui concernent un incident de service n'en portent pas. AWS User Notifications et Amazon EventBridge permettent de les acheminer. Preuve : la règle d'acheminement et la file où un propriétaire les traite.
18. Chaque notification adressée à un humain demande une action. Une alerte qui n'appelle aucune action devient du bruit, et le bruit retombe sur la seule personne qui sait le trier. La répartition des alertes entre appel immédiat, ticket et tableau de bord est détaillée dans Des alertes qui sonnent pour rien : un socle d'observabilité pour une scale-up sans SRE. Preuve : chaque alerte a un propriétaire et une procédure.
19. L'usage de l'utilisateur racine déclenche une alerte reçue par plusieurs personnes. AWS recommande de surveiller, d'alerter et de rendre compte de chaque connexion et de chaque usage des identifiants racine, et de prévoir une procédure pour valider que l'accès était attendu ou escalader s'il ne l'était pas. Preuve : la règle d'alerte, ses destinataires et la procédure de vérification.
20. Les accès inutilisés sont revus à date fixe. Le service IAM fournit des informations de dernier accès pour repérer les utilisateurs, rôles, permissions et identifiants qui ne servent plus. Une revue régulière, et une revue à chaque départ, évitent qu'un accès oublié devienne lui aussi une dépendance. Preuve : la date de la dernière revue et ses décisions.

Pour vérifier le point 16, lancez ces commandes en lecture seule ; elles demandent la permission account:GetAlternateContact. À adapter à votre environnement :

# Lecture seule : affiche les contacts alternatifs du compte courant
# Une erreur ResourceNotFoundException signifie que ce type de contact n'est pas renseigné
aws account get-alternate-contact --alternate-contact-type=OPERATIONS
aws account get-alternate-contact --alternate-contact-type=SECURITY
aws account get-alternate-contact --alternate-contact-type=BILLING

# Depuis le compte de gestion d'une organisation (accès de confiance activé)
aws account get-alternate-contact --account-id <ID_COMPTE_MEMBRE> --alternate-contact-type=SECURITY

Tester la couverture avant l'absence

Une liste cochée ne prouve pas qu'une autre personne saura agir. La seule preuve est un geste exécuté par quelqu'un d'autre, avec la documentation pour seule aide. Le bon moment pour le vérifier est celui où la personne clé est présente : elle peut observer, corriger la procédure et rattraper une erreur.

Le livre de Google sur l'ingénierie de la fiabilité (SRE, Site Reliability Engineering) décrit des pratiques voisines pour former une personne avant de lui confier la production : des exercices de jeu de rôle sur une panne simulée, que ses auteurs appellent « Wheel of Misfortune », des périodes où la personne en formation suit en observatrice une personne expérimentée, et la mise à jour des parties les plus obsolètes de la documentation par celles et ceux qui en ont le plus besoin. AWS demande de même de tester périodiquement l'accès d'urgence, et la documentation d'IAM Identity Center recommande de tester sa configuration d'urgence pour que l'équipe sache quoi faire en cas d'interruption d'IAM Identity Center. Cette configuration repose toujours sur le fournisseur d'identité externe : elle ne couvre pas sa panne, d'où le compte d'urgence distinct du premier schéma.

Le protocole, en cinq étapes

Jouez ce protocole hors production ou sur des gestes en lecture seule, avec l'accord explicite des participants.

1. Choisir les gestes critiques. La direction et la personne clé dressent ensemble une courte liste, à partir de l'inventaire du point 7 : connexion d'administration, déploiement d'une correction, restauration d'une base, rotation d'un secret, renouvellement d'un domaine ou d'un certificat, révocation d'un accès, accès d'urgence.
2. Désigner un exécutant et un observateur. L'exécutant n'est pas la personne clé. L'observateur note l'heure, chaque blocage et chaque question posée. La personne clé assiste, en silence, et n'intervient que si le geste met en danger un système.
3. Exécuter avec la procédure comme seule aide. Chaque question posée à la personne clé est un écart : une étape manquante, un accès absent, un prérequis implicite. L'écart est consigné, jamais reproché.
4. Corriger dans le dépôt, puis rejouer. La procédure est corrigée par l'exécutant, relue par la personne clé, puis rejouée par une troisième personne si l'équipe le permet. Un geste n'est couvert que lorsqu'il a été exécuté sans aide.
5. Mettre à jour la matrice de couverture. Pour chaque geste et chaque personne, une case : « exécuté seul le <date> », « exécuté avec aide le <date> » ou « jamais ». La matrice sert au dirigeant ; elle ne classe pas les personnes et ne se publie pas hors de l'équipe concernée.

L'absence simulée

Quand la matrice montre au moins deux exécutants pour chaque geste critique, l'étape suivante est une absence simulée : une période convenue à l'avance pendant laquelle la personne clé ne répond plus aux questions sur la plateforme, tout en restant joignable par un canal d'urgence défini. Chaque recours à ce canal est un écart, traité comme à l'étape 3. Cette période se place en dehors des livraisons importantes, et la direction l'annonce comme un exercice de l'organisation.

L'exercice montre ce que l'équipe sait faire dans des conditions préparées, pas dans une panne réelle sous pression : il réduit l'incertitude sans la supprimer.

Un plan sur 30 jours pour réduire la dépendance

Le plan ordonne les vingt points par urgence. Il ne suppose aucun recrutement et peu de moyens nouveaux (un coffre hors du compte, des dispositifs MFA physiques), mais surtout du temps de la personne clé, que la direction doit dégager explicitement : sinon, le plan s'ajoute à une charge déjà concentrée sur elle.

Semaine 1 : les accès

• Passer l'adresse de l'utilisateur racine sur une adresse de groupe (point 1), enregistrer un deuxième dispositif MFA au moins, détenu par une autre personne ou rangé à un endroit connu (point 2).
• Ranger le mot de passe racine dans un coffre hors du compte, séparer la gestion de la boîte de récupération et celle du numéro de téléphone (points 3 et 4).
• Renseigner les trois contacts alternatifs avec des listes de l'entreprise (point 16).
• Vérifier qu'une deuxième personne dispose d'un accès d'administration nominatif (point 5).

Sortie attendue : l'entreprise peut entrer dans ses comptes AWS et recevoir les messages d'AWS sans la personne clé.

Semaine 2 : le savoir

• Dresser l'inventaire (point 7) et la liste des gestes critiques.
• Faire écrire par la personne clé les procédures des deux ou trois gestes les plus critiques (point 9), dans le dépôt de l'entreprise.
• Faire jouer chacune de ces procédures par une autre personne, selon le protocole du chapitre précédent.
• Ouvrir le registre de décisions (point 11) et dater le schéma d'architecture (point 8).

Sortie attendue : une matrice de couverture partielle, avec ses premiers écarts consignés.

Semaine 3 : la continuité

• Poser les deux questions du RTO et du RPO à la direction et consigner les réponses signées (points 12 et 13).
• Faire jouer une restauration complète par une autre personne que la personne clé, avec vérification des données et mesure de la durée (points 14 et 15).
• Concevoir, créer et tester l'accès d'urgence (point 6), puis brancher l'alerte sur l'usage de l'utilisateur racine (point 19).

Sortie attendue : un compte rendu de restauration daté et un test d'accès d'urgence daté.

Semaine 4 : l'exploitation et la décision

• Acheminer les événements AWS Health vers une file avec un propriétaire (point 17), trier les alertes existantes (point 18), fixer la date de la prochaine revue des accès (point 20).
• Compléter la matrice de couverture et, si chaque geste critique a deux exécutants, planifier l'absence simulée.
• Tenir une revue de direction sur trois éléments : le nombre de gestes critiques encore tenus par une seule personne, la date du dernier test d'accès d'urgence, la date de la dernière restauration jouée par une autre personne.

Sortie attendue : une liste d'écarts restants, chacun avec un propriétaire et une date.

Après les 30 jours

Les écarts restants appellent une décision de la direction : former une personne de l'équipe, recruter, ou confier une partie de l'exploitation à un tiers. Ce dernier choix ne règle rien s'il déplace simplement la personne clé de l'entreprise vers le fournisseur ; les critères pour en décider sont détaillés dans Externaliser l'exploitation cloud et Kubernetes : que confier, à qui et avec quel contrat. Si vous choisissez de faire porter l'exploitation par CTN Solutions, nous commençons par rendre visibles les dépendances, les accès et les procédures avant d'accepter un périmètre, comme le décrit la reprise d'exploitation sur notre page Infogérance cloud & maintien en conditions opérationnelles (MCO). Quel que soit le choix, les accès racine, l'accès d'urgence et les dépôts restent sous le contrôle de l'entreprise ; un exploitant externe reçoit des accès nominatifs.

Le plan se rejoue ensuite à chaque arrivée ou départ dans l'équipe, et à chaque changement important de la plateforme : un bus factor remonte lentement et redescend en une démission.

Sources officielles et limites de lecture

L'article porte sur AWS ; Google Cloud et Microsoft Azure proposent des mécanismes comparables. Les points sur l'utilisateur racine concernent les comptes AWS créés par l'inscription classique, appelée « Sign up for AWS (advanced) » ; ceux sur les contacts alternatifs valent aussi pour un compte dont les fonctions avancées ont été activées. Un compte créé avec la nouvelle expérience d'inscription d'AWS n'a pas d'utilisateur racine, même après cette activation, et se gère dans AWS Settings. Le découpage du plan en quatre semaines fixe un ordre de priorité, pas une estimation de charge : le RTO, le RPO et le rythme des tests se décident chez vous, à partir de votre activité.

Sources

1. The Theory and Practice of Computing the Bus-Factor, arXiv:2603.07845 (8 mars 2026) : https://arxiv.org/abs/2603.07845
2. Bus Factor In Practice, ICSE 2022 (SEIP), arXiv:2202.01523 : https://arxiv.org/abs/2202.01523
3. Contributor Absence Factor (anciennement Bus Factor), CHAOSS (Linux Foundation) : https://www.chaoss.community/kb/metric-contributor-absence-factor/
4. Root user best practices for your AWS account, Amazon Web Services : https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
5. Security best practices in IAM, Amazon Web Services : https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
6. What is IAM Identity Center?, Amazon Web Services : https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
7. SEC03-BP03 Establish emergency access process, AWS Well-Architected Framework, Amazon Web Services : https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_emergency_process.html
8. Set up emergency access to the AWS Management Console, AWS IAM Identity Center User Guide, Amazon Web Services : https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html
9. REL13-BP01 Define recovery objectives for downtime and data loss, AWS Well-Architected Framework, Amazon Web Services : https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html
10. REL09-BP04 Perform periodic recovery of the data to verify backup integrity and processes, AWS Well-Architected Framework, Amazon Web Services : https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html
11. Update the alternate contacts for your AWS account, AWS Account Management Reference Guide, Amazon Web Services : https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html
12. Concepts for AWS Health, AWS Health User Guide, Amazon Web Services : https://docs.aws.amazon.com/health/latest/ug/aws-health-concepts-and-terms.html
13. Capabilities: Documentation quality, DORA (Google Cloud) : https://dora.dev/capabilities/documentation-quality/
14. Accelerating SREs to On-Call and Beyond, Site Reliability Engineering, Google : https://sre.google/sre-book/accelerating-sre-on-call/
15. Compare sign-up options, AWS Account Management Reference Guide, Amazon Web Services : https://docs.aws.amazon.com/accounts/latest/reference/sign-up-for-aws.html
16. GetAlternateContact, AWS Account Management API Reference, Amazon Web Services : https://docs.aws.amazon.com/accounts/latest/APIReference/API_GetAlternateContact.html