Key takeaway
Documenter Plan, Do, Check et Act ne rendra pas votre ISMS mature. Ce qui le rend mature, c’est la manière dont les quatre phases s’articulent. Les risques orientent vos mesures de sécurité, vous mettez en œuvre ces mesures et évaluez leur efficacité, et ce que vous apprenez façonne le cycle suivant. Sans cette boucle, le PDCA n’est que quatre activités distinctes. Avec elle, vous disposez d’un système de management qui s’améliore au fil du temps.
Plan, Do, Check, Act. Cela paraît simple et, en théorie, ça l’est. Le cycle a près de cent ans, et la norme ISO 27001 reste construite autour de lui. Connaître les quatre étapes est facile. Les faire fonctionner dans un véritable ISMS, c’est là que la plupart des organisations éprouvent des difficultés. Ce blog explique ce que signifie le PDCA dans le contexte de l’ISO 27001, comment chaque phase s’inscrit dans la norme et quelles sont les erreurs les plus courantes à éviter lors de la mise en place de votre système de management de la sécurité de l’information.
PDCA en bref
PDCA signifie Plan, Do, Check, Act : quatre étapes que vous répétez pour améliorer un processus de manière structurée. Ce n’est pas une solution miracle, et vous n’en avez jamais vraiment « fini ». Les risques, les vulnérabilités et les menaces évoluent sans cesse, le cycle doit donc tourner en permanence. Vous ajustez, puis vous repartez pour un tour. Sans cette répétition, la cybersécurité devient un assemblage de pièces détachées : un pare-feu par-ci, une formation par-là, et personne pour vérifier si l’ensemble tient toujours la route.
- Plan: où se situent vos risques et que comptez-vous faire pour y remédier ?
- Do: Mise en pratique de ces mesures.
- Check: résistent-elles sous pression ? Testez-les.
- Act: qu’avez-vous appris, et comment allez-vous l’intégrer dans le cycle suivant ?
Le cycle PDCA, également appelé…
Le PDCA est également connu sous le nom de cycle de Deming ou de roue de Deming. Paradoxalement, l’homme dont le nom est le plus souvent associé à la méthode ne l’a lui-même jamais appelée ainsi.
Qui a inventé le PDCA?
La méthode a d’abord été développée par Walter A. Shewhart, physicien américain et pionnier de la qualité. Dans les années 1930, il travaillait chez Bell Labs sur un problème concret : comment produire des composants téléphoniques systématiquement exempts de défauts. Il a baptisé son modèle « cycle de Shewhart » et l’a fondé sur la méthode scientifique : hypothèse, expérimentation, évaluation. Le terme PDCA (Plan-Do-Check-Act) n’est apparu que plus tard.
Quelle est la différence entre PDCA et PDSA?
William Edwards Deming, un protégé de Shewhart, a repris le concept et l’a introduit au Japon dans les années 1950. De là, il s’est fait connaître dans le monde entier, ce qui explique pourquoi la méthode porte également son nom. Le terme PDCA tel que nous le connaissons aujourd’hui n’est apparu qu’à cette époque : des participants japonais aux conférences de Deming ont retravaillé son modèle pour en faire le « Plan-Do-Check-Act ». Deming lui-même n’a jamais adopté ce terme. Il préférait Plan-Do-Study-Act (PDSA), car il estimait que « Study » traduisait mieux l’essentiel. Pour lui, la troisième étape consistait à tirer des enseignements de ce qui s’était passé, et pas simplement à le vérifier.
En pratique, la distinction ne change pas grand-chose. Que vous parliez de PDCA ou de PDSA, l’idée sous-jacente reste la même : une amélioration structurée et continue.
Le cycle PDCA est-il encore pertinent aujourd’hui?
Aujourd’hui, vous ne trouverez plus de mention du PDCA dans l’ISO 27001. Pourtant, le principe y est toujours bien présent. Vous pouvez encore l’appliquer aux articles de la norme, même si le texte lui-même n’utilise plus ce terme. C’est pourquoi le PDCA reste une grille de lecture utile : une fois que vous répartissez les articles en quatre étapes familières, ils deviennent bien plus faciles à comprendre et à mettre en pratique. Et cela vous offre un moyen concret d’atteindre l’amélioration continue exigée par toute norme ISO de système de management.
Les articles 1 à 3 (Domaine d’application, Références normatives, Termes et définitions) ne figurent pas dans cet aperçu. Ils sont purement informatifs et ne contiennent aucune exigence à proprement parler. Le vrai travail commence à l’article 4.
A quoi ressemble concrètement le cycle PDCA dans le cadre de l’ISO 27001 ?
Sur papier, cela paraît simple. Mais si vous mettez en place un ISMS aujourd’hui, quatre mots abstraits ne vous mèneront pas bien loin. Chaque étape doit être concrétisée. Quels risques identifiez-vous dans Plan ? Quelles mesures relèvent de Do ? Comment vérifiez-vous dans Check si elles fonctionnent réellement ? Et à quoi ressemble concrètement un ajustement de cap dans Act ?
Voici comment les quatre étapes se traduisent dans une mise en œuvre de l’ISO 27001 :
1. Plan
- Cartographiez le contexte de votre organisation : les enjeux internes et externes, ainsi que vos parties intéressées
- Déterminez le domaine d’application de l’ISMS : quels processus, sites et systèmes couvre-t-il ?
- Impliquez la direction : faites-la contribuer à l’élaboration de la politique de sécurité de l’information et en assurer activement la promotion, plutôt que de simplement la lui faire signer.
- Attribuez les rôles et les responsabilités.
- Réalisez une appréciation des risques : identifiez vos processus métier critiques et les risques qui y sont liés, et fixez les critères que vous utiliserez pour évaluer ces risques.
- Utilisez les résultats pour décider du traitement des risques : quelles mesures sont prioritaires ?
- Fixez des objectifs de sécurité de l’information mesurables.
2. Do
- Mettez en œuvre des mesures techniques (p. ex. authentification multifacteur, segmentation du réseau)
- Déployez de nouvelles procédures, comme un plan de réponse aux incidents
- Formez le personnel et la direction à leur rôle dans ces procédures
3. Check
- Surveillez en continu si vos mesures fonctionnent efficacement
- Collectez des indicateurs, comme les délais de réaction ou le nombre d’incidents signalés
- Analysez les incidents signalés et les quasi-incidents
- Évaluez ces données : les résultats atteignent-ils les objectifs que vous avez fixés ?
- Réalisez des audits internes pour vérifier formellement si l’ISMS dans son ensemble répond toujours aux exigences de la norme
- Testez votre niveau de préparation au moyen d’exercices (p. ex. une simulation de phishing ou un exercice sur table)
4. Act
- Pour chaque non-conformité ou incident, regardez au-delà du symptôme et identifiez la cause sous-jacente : c’est l’analyse des causes profondes
- Mettez à jour les politiques et les procédures sur la base de ces constats d’audit ou de ces incidents
- Remontez les lacunes structurelles à la direction
- Réinjectez les enseignements tirés dans la phase Plan, afin que le cycle suivant démarre avec une vision plus claire plutôt qu’avec le même angle mort
Quelles sont les erreurs PDCA courantes lors d’une mise en oeuvre de l’ISO 27001 ?
Appréciation des risques réalisée. Terminé ?
Vous pouvez disposer d’une appréciation des risques techniquement irréprochable. Mais si personne n’en est responsable, si personne n’a le temps ni les moyens d’y donner suite et si la direction ne la soutient pas, ce n’est qu’un fichier de plus qui traîne quelque part dans le cloud.
De nombreuses organisations réduisent Plan à une seule étape : l’appréciation des risques. Elle est importante, bien sûr, mais elle ne couvre que l’article 6. La phase Plan complète comprend également le contexte de l’organisation (article 4), le leadership et l’engagement de la direction (article 5), ainsi que les ressources et les compétences nécessaires pour passer à l’action (article 7).
Publiée. Mais mise en pratique ?
L’article 8 porte sur le fonctionnement et, dans ce contexte, cela va bien au-delà de la publication d’une politique sur l’intranet. Il vous faut un plan opérationnel : des actions concrètes, chacune avec un responsable et une échéance.
Disposer d’une politique, c’est une déclaration d’intention. La mettre en œuvre, c’est agir en conséquence, jour après jour. Tant qu’une politique ne se reflète pas dans la manière dont les gens travaillent réellement, elle relève encore de Plan.
Vérifier une fois par an ? Ce n’est pas du “Check”.
L’audit interne (article 9.2) est la partie la plus connue de Check, mais ce n’est pas la seule. L’article 9.1 exige la surveillance et la mesure : évaluer en continu si vos dispositifs fonctionnent, et pas uniquement lorsque l’auditeur s’annonce. Une organisation qui ne vérifie qu’une fois par an passe à côté de tout ce qui change entre-temps. Check comprend également la revue de direction (article 9.3), au cours de laquelle la direction évalue si l’ISMS est toujours pertinent et efficace, et ce qui doit changer.
En bref, Check est un processus continu de mesure et de suivi, auquel s’ajoutent l’audit interne annuel et la revue de direction en tant que points de contrôle formels. Sans cette surveillance continue, vous risquez de ne découvrir qu’au prochain audit, parfois des mois plus tard, que quelque chose a mal tourné depuis longtemps.
La faille peut être colmatée mais le problème demeure.
Lorsque quelque chose tourne mal, qu’un audit relève une non-conformité ou qu’un incident réel se produise, la plupart des organisations partent du principe que “Act” consiste simplement à corriger ce problème précis. Une vulnérabilité a été découverte ? On déploie le correctif, on coche la case, terminé.
L’article 10 en demande davantage. Vous devez également rechercher la cause profonde : pourquoi le problème s’est produit au départ. Ce n’est que lorsque cette cause profonde est réinjectée dans Plan que le cycle se referme véritablement. C’est ainsi que vous évitez que la même faiblesse ne refasse surface quelques mois plus tard sous une autre forme.
