7 points faibles de ton modèle de prestation à corriger avant ton prochain audit ou ta prochaine panne

Un auditeur qui te demande des preuves de ton processus de déploiement et une analyse d’incident qui cherche à savoir ce qui a mal tourné posent en fait les mêmes questions. La différence, c’est le moment où ça arrive. L’un repère le point faible avant que ça ne te coûte quoi que ce soit. L’autre le repère en plein milieu d’une panne, avec un client au téléphone.

1. Environnements incohérents

Le développement, la préproduction et la production se sont discrètement éloignés les uns des autres, si bien qu’un changement qui fonctionne dans un environnement ne se comporte pas de la même manière dans un autre. Cela passe généralement inaperçu jusqu’à ce qu’un problème survienne en production, que personne ne parvient à reproduire ailleurs.

La solution : chaque environnement est provisionné à partir de la même définition, donc il n’y a plus de « presque identique » entre le pré-production et la production qui puisse prêter à controverse.

Pose-toi la question : l’environnement de préproduction est-il cohérent avec celui de production, ou y a-t-il une catégorie d’erreurs que notre préproduction ne peut pas détecter à cause d’incohérences entre ces deux environnements ?

2. Étapes de déploiement manuelles

À un moment donné dans le processus de mise en production, il y a une étape qu’une personne doit penser à effectuer manuellement : un paramètre de configuration, une migration de base de données, un vidage du cache. Ça marche bien jusqu’à ce que la personne qui s’en souvient d’habitude soit absente.

La solution : le pipeline de mise en production est entièrement automatisé et harmonisé entre les environnements, de sorte que le processus se déroule de la même manière, que la bonne personne soit attentive ce jour-là ou non.

Pose-toi la question : est-ce que quelqu’un qui n’a jamais géré de mise en production pourrait s’en charger en suivant uniquement le guide d’intervention, sans avoir à contacter la personne qui s’en occupe d’habitude ?

3. Responsabilité floue

Demande à qui appartient un service donné, et tu obtiens plusieurs réponses, ou un haussement d’épaules. Quand quelque chose plante, les vingt premières minutes sont consacrées à déterminer qui devrait s’en occuper, et non à le réparer.

La solution : chaque service a un responsable clairement identifié et les niveaux d’accès au projet reflètent la structure de l’organisation.

Pose-toi la question : si tu demandais à trois personnes différentes à qui appartient ce service, obtiendrais-tu trois réponses différentes ? Les responsables sont-ils réellement capables de procéder au déploiement ?

4. Une procédure de retour en arrière insuffisante

Le plan, c’est d’aller de l’avant avec un correctif. La restauration, c’est ce que personne n’a testé depuis le dernier incident.

Une solution correcte, c’est ça : la réversion est une procédure testée et mise en pratique, et les sauvegardes peuvent être restaurées de manière autonome.

Pose-toi la question : à quand remonte la dernière fois où ton équipe a effectué une restauration en arrière, et ça s’est-il bien passé ? La procédure de restauration en arrière est-elle documentée et testée ?

5. Dérive de configuration

Les variables d’environnement, les indicateurs de fonctionnalités et les paramètres d’infrastructure en production ont accumulé des modifications qui n’ont jamais été entièrement répercutées dans le contrôle de version. Ce qui tourne réellement et ce que le dépôt indique comme étant en cours d’exécution sont deux choses différentes.

Solution : la configuration est intégrée au code, le même code qui est revu et versionné, pour que la production ne s’écarte jamais discrètement de ce qui est documenté.

Pose-toi la question : est-ce que je me sens en confiance pour détruire et reconstruire mes environnements ?

6. Contrôle d’accès insuffisant

Un accès a été accordé pour un projet qui s’est terminé il y a huit mois et n’a jamais été révoqué. Un stagiaire de l’été dernier peut encore, techniquement, pousser des modifications en production. Personne ne surveille qui a le droit de toucher à quoi.

La solution, ça donne ça : les accès sont liés au rôle actuel et aux besoins du moment, et ils sont revus régulièrement au lieu de s’accumuler jusqu’à ce que quelqu’un pose la question lors d’un audit.

Demande-toi : la liste des accès est-elle intégrée au système de déploiement, ou les accès sont-ils gérés manuellement ? D’anciens collaborateurs peuvent-ils encore accéder à ton code ou à ton infrastructure ?

7. Faible prévisibilité des déploiements

Certains déploiements sont routiniers. D’autres sont un petit événement : prudence redoublée, quelques personnes en stand-by, un fil de discussion Slack intitulé « au cas où ». Si tu ne peux pas prédire quels déploiements se passeront sans incident, c’est ton processus qui est la variable, pas le code.

La solution : les déploiements sont ennuyeux, et c’est voulu, car le processus qui les sous-tend est suffisamment cohérent pour que personne n’ait à se préparer à en affronter un.

Pose-toi la question : en repensant à tes dix derniers déploiements, aurais-tu pu prévoir à l’avance lesquels nécessiteraient une vigilance particulière ?

Pour y remédier, il suffit surtout de rendre le processus de livraison suffisamment cohérent pour qu’il ne dépende plus de la personne qui est attentive ce jour-là, et non pas d’embaucher une équipe de sécurité ou de lancer un gros programme de conformité.

C’est aussi ce qu’une plateforme standardisée comme Upsun Cloud est conçue pour faire automatiquement à ta place : cohérence de l’environnement, contrôle d’accès et retour en arrière gérés au niveau de la plateforme, plutôt que maintenus manuellement sur l’ensemble des sept points faibles.

• À lire aussi : Avant de créer ta propre plateforme interne, fais ces calculs
• Tu veux savoir précisément lesquels de ces sept points s’appliquent à ta configuration, et ce qu’il faudrait faire pour y remédier ? Réserve un bilan de sécurité et de fiabilité.

Foire aux questions (FAQ)

Cette liste est-elle spécifique à un cadre de conformité particulier, comme SOC 2 Type 2 ou ISO 27001 ?
Non. Ces sept points faibles apparaissent quel que soit le cadre de référence, car les auditeurs et les analyses d’incidents finissent tous par examiner la manière dont les logiciels sont réellement développés et déployés, et pas seulement les contrôles de sécurité sur le papier.

Lequel de ces sept points faibles est à l’origine du plus grand nombre d’incidents ?
Les environnements incohérents et les étapes de déploiement manuelles ont tendance à apparaître le plus souvent, car ce sont eux qui sont les plus susceptibles de se comporter différemment selon le jour, la personne ou l’environnement concerné.

Comment savoir si la dérive de configuration est déjà un problème ?
Si personne ne peut affirmer avec certitude, sans vérifier, que la configuration en production correspond à celle du contrôle de version, une dérive s’est probablement déjà produite. L’écart a tendance à rester caché jusqu’à ce que quelqu’un procède à une vérification.

Faut-il corriger les sept points avant un audit ?
Pas forcément tous en même temps, mais ça vaut le coup de savoir lesquels s’appliquent avant qu’un auditeur ou un incident ne les repère à ta place. Corriger d’abord ceux qui présentent le plus de risques est généralement plus réaliste que d’essayer de régler les sept d’un seul coup.