Procédure informatique – modèle pour le service IT

Une procédure informatique pensée pour l'exploitation réelle — systèmes, accès, changements et gestion des incidents.

Fait partie de nos Modèles SOPgratuits.

Télécharger Word (.docx)

Télécharger PDF Gratuit · Pas d’inscription · Pas de filigrane

1.Cartouche et maîtrise documentaire

Titre de la procédure {{Titre de la procédure}}
Référence {{Référence}}
Version {{Version}}
Date d'application {{Date d'application}}
Date de révision {{Date de révision}}
Rédacteur / propriétaire {{Rédacteur / propriétaire}}
Approbateur {{Approbateur}}

Gardez ce cartouche en page 1 pour que n'importe qui puisse auditer le document d'un coup d'œil. Fixez une date de révision à 6–12 mois et désignez un seul propriétaire responsable de sa mise à jour.

2.Objet

Indiquez en une ou deux phrases pourquoi cette procédure existe et quel résultat elle produit lorsqu'elle est correctement appliquée.

Écrivez le « pourquoi », pas les étapes. Exemple : « Cette procédure garantit que chaque remboursement client est traité correctement, dans le respect de la politique commerciale et sous deux jours ouvrés. »

3.Domaine d'application

Définissez à quelles équipes, sites, systèmes et situations cette procédure s'applique — et précisez explicitement ce qu'elle ne couvre pas.

Nommer les limites évite d'appliquer la procédure aux mauvais cas. Listez les exclusions sur une ligne à part.

Systèmes et outils concernés

Système / outilUsageResponsableCriticité
{{Système}}{{À quoi il sert}}{{Équipe / rôle}}{{Critique / élevée / faible}}
{{Système}}{{À quoi il sert}}{{Équipe / rôle}}{{Criticité}}
{{Gestion des identités et des accès}}{{SSO, MFA, attribution des droits}}{{IT / sécurité}}{{Critique}}

Listez les systèmes touchés par cette procédure, qui en est responsable et à quel point ils sont critiques. Nommer le système de référence et son responsable évite que des accès, des changements ou des incidents passent entre les mailles.

4.Définitions et abréviations

TermeDéfinition
{{Terme}}{{Définition en langage clair}}
{{Abréviation}}{{Signification}}

Ne définissez que les termes qu'un nouvel arrivant pourrait mal comprendre. S'il n'y en a pas, conservez la section et écrivez « Néant » — les auditeurs s'attendent à la trouver.

5.Rôles et responsabilités

RôleResponsabilité
{{Rôle}}{{Ce dont ce rôle est responsable dans cette procédure}}
{{Rôle}}{{Ce dont ce rôle est responsable dans cette procédure}}

Attribuez les responsabilités à des rôles, pas à des personnes nommées, pour que la procédure survive aux changements d'équipe. Une à deux lignes par rôle.

6.Prérequis, matériel et équipements

  • {{Accès ou habilitation nécessaire avant de commencer}}
  • {{Outil, système ou identifiant requis}}
  • {{Matériel ou document devant être disponible}}

Listez tout ce qui doit être prêt avant l'étape 1. Une courte checklist évite les exécutions à moitié terminées.

7.Sécurité et conformité

Indiquez les précautions de sécurité ainsi que la réglementation, les normes et les politiques internes que cette procédure doit respecter.

Si la procédure n'a aucun enjeu de sécurité ou de conformité, conservez la section et écrivez « Sans objet ». Citez nommément la réglementation, la norme ou la politique interne concernée.

8.Procédure (étape par étape)

ÉtapeActionResponsableRésultat attendu
1{{Commencez par un verbe — une action par étape}}{{Rôle}}{{À quoi ressemble une étape bien faite}}
2{{Action suivante}}{{Rôle}}{{Résultat attendu}}
3{{Action suivante}}{{Rôle}}{{Résultat attendu}}

Visez 5 à 15 étapes numérotées. Chacune commence par un verbe, ne contient qu'une action et décrit un résultat observable, pour que chacun puisse vérifier que l'étape est terminée.

9.Contrôles qualité et critères d'acceptation

  • {{Contrôle mesurable confirmant que le travail a été fait correctement}}
  • {{Deuxième critère d'acceptation}}

Rédigez 2 à 4 contrôles mesurables — un vérificateur doit pouvoir répondre à chacun par un oui ou un non clair.

10.Anomalies et exceptions

AnomalieQue faireEscalade vers
{{Problème fréquent}}{{Action corrective}}{{Rôle / contact}}
{{Cas particulier}}{{Comment le traiter}}{{Rôle / contact}}

Consignez les anomalies réellement rencontrées. Nommer le niveau d'escalade évite que les exceptions restent bloquées.

11.Documents associés et références

  • {{Formulaire, checklist ou politique sur laquelle repose cette procédure}}
  • {{Procédure amont ou aval}}

Reliez les formulaires, politiques et procédures voisines dont le lecteur aura besoin ensuite.

12.Historique des révisions

VersionDateAuteurRésumé de la modification
1.0{{Date d'application}}{{Rédacteur / propriétaire}}Première diffusion
{{Version}}{{Date}}{{Auteur}}{{Ce qui a changé}}

Mettez ce tableau à jour à chaque modification. La ligne 1.0 est pré-remplie à titre d'exemple.

13.Approbation

Rédacteur Nom Signature Date
Approbateur Nom Signature Date

Les deux signatures confirment que la procédure est exacte et autorisée à être appliquée.

Un exemple rempli pour une équipe d'exploitation, avec matrice de gravité.

1.Cartouche et maîtrise documentaire

Titre de la procédure Traitement d'un incident de production
Référence IT-014
Version 1.0
Date d'application 1er juin 2026
Date de révision 1er juin 2027
Rédacteur / propriétaire Responsable d'exploitation
Approbateur Directeur des systèmes d'information

2.Objet

Cette procédure garantit qu'un incident de production est qualifié, pris en charge et communiqué dans les mêmes délais quelle que soit la personne d'astreinte, et qu'il donne lieu à une analyse écrite.

3.Domaine d'application

Couvre les incidents affectant les services en production (site de vente, API de paiement, base de données). Ne couvre pas les demandes d'assistance courantes (IT-002) ni les changements planifiés (IT-009).

Systèmes et outils concernés

Système / outilUsageResponsableCriticité
Site de venteCommandes clientsÉquipe produitCritique
API de paiementEncaissementÉquipe paiementCritique
Supervision et alertesDétection des incidentsExploitationÉlevée
Gestion des identités (SSO/MFA)Accès aux consoles d'administrationIT / sécuritéCritique

4.Définitions et abréviations

TermeDéfinition
P1 / P2 / P3Niveaux de gravité, du plus critique au moins critique
AstreinteSalarié joignable hors horaires pour intervenir sur un incident
Post-mortemAnalyse écrite après incident, sans recherche de responsable individuel

Niveaux de gravité et délais de prise en charge

GravitéDéfinitionPrise en chargeInformation
P1 — critiqueService indisponible ou données exposéesImmédiate, astreinte activéeDirection et clients sous 1 h
P2 — majeureFonction dégradée, contournement possibleSous 2 h ouvréesResponsables métier
P3 — mineureGêne limitée, sans impact métierProchain jour ouvréDemandeur uniquement

5.Rôles et responsabilités

RôleResponsabilité
Technicien d'astreinteQualifie l'incident, applique le contournement et tient le journal
Responsable d'exploitationDécide de l'escalade et pilote la communication
Directeur des systèmes d'informationInforme la direction et décide d'une notification à la CNIL en cas de violation de données

6.Prérequis, matériel et équipements

  • Accès à la supervision et au canal d'astreinte
  • Annuaire d'escalade à jour
  • Procédure de retour arrière du dernier déploiement
  • Compte nominatif avec MFA sur les consoles concernées

7.Sécurité et conformité

Aucune donnée personnelle n'est extraite d'un système de production pour analyse ; les investigations se font sur les journaux. En cas de violation de données à caractère personnel, la notification à la CNIL doit être envoyée dans les 72 heures (article 33 du RGPD) et le DPO alerté immédiatement. Toute action d'administration est effectuée depuis un compte nominatif, jamais un compte partagé.

8.Procédure (étape par étape)

ÉtapeActionResponsableRésultat attendu
1Accuser réception de l'alerte et ouvrir le journal d'incidentTechnicien d'astreinteIncident enregistré avec horodatage
2Qualifier la gravité (P1/P2/P3) selon le tableauTechnicien d'astreinteGravité tracée et délais engagés
3Appliquer le contournement ou le retour arrièreTechnicien d'astreinteService rétabli ou impact réduit
4Informer les parties prenantes selon la gravitéResponsable d'exploitationMessage envoyé dans le délai prévu
5Vérifier le rétablissement par la supervisionTechnicien d'astreinteIndicateurs revenus à la normale sur 30 minutes
6Clôturer et planifier le post-mortem sous 5 jours ouvrésResponsable d'exploitationPost-mortem programmé avec actions correctives

9.Contrôles qualité et critères d'acceptation

  • La gravité et l'heure de prise en charge sont enregistrées
  • Le service est confirmé rétabli par la supervision, pas seulement à l'œil
  • Les parties prenantes ont été informées dans le délai de leur niveau
  • Un post-mortem avec actions et responsables est planifié

10.Anomalies et exceptions

AnomalieQue faireEscalade vers
Aucune réponse de l'astreinte sous 15 minutesEscalader au niveau suivant de l'annuaireResponsable d'exploitation
Suspicion de fuite de données personnellesAlerter immédiatement le DPO et geler les accès concernésDirecteur des systèmes d'information
Le retour arrière échoueBasculer sur le plan de continuité et convoquer la cellule de criseResponsable d'exploitation

11.Documents associés et références

  • IT-002 Procédure de demande d'assistance
  • IT-009 Gestion des changements
  • Politique de sécurité du système d'information (PSSI)

12.Historique des révisions

VersionDateAuteurRésumé de la modification
1.01er juin 2026Responsable d'exploitationPremière diffusion

13.Approbation

Rédacteur Nom Signature Date
Approbateur Nom Signature Date

Procédure informatique : ce que le modèle contient

Le modèle reprend les sections d'une procédure classique et ajoute ce qui manque toujours aux procédures IT :

  • Tableau des systèmes et outils concernés, avec responsable et criticité
  • Règles d'accès : moindre privilège, MFA, comptes nominatifs
  • Gestion des changements en production avec plan de retour arrière
  • Exemple d'incident avec niveaux de gravité et délais de prise en charge
  • Contrôles, escalades, historique des révisions et approbation

Un exemple rempli : incident de production

L'exemple suit un incident de bout en bout : qualification P1/P2/P3, contournement ou retour arrière, information des parties prenantes selon la gravité, vérification par la supervision et post-mortem sous cinq jours ouvrés. Il inclut l'escalade RGPD en cas de suspicion de fuite de données.

Comment ça marche

  1. Consultez la procédure informatique complète, avec l'exemple d'incident de production.
  2. Téléchargez-la en Word (.docx) ou PDF, ou copiez le texte pour Google Docs.
  3. Renseignez vos systèmes, vos niveaux de gravité et votre annuaire d'escalade.

Questions fréquemment posées

Qu'est-ce qu'une procédure informatique ?

Une procédure informatique décrit comment une opération du service IT est réalisée de façon reproductible : traitement d'un incident, attribution ou retrait d'accès, sauvegarde et restauration, mise en production. Elle nomme les systèmes concernés, les rôles, les étapes et les contrôles, pour que le résultat ne dépende pas de la personne d'astreinte.

Quelles procédures écrire en premier dans un service informatique ?

Celles dont l'absence se paie immédiatement : le traitement des incidents, l'arrivée et le départ d'un collaborateur (attribution et retrait des accès), la gestion des changements en production et la restauration des sauvegardes. Ce sont aussi les premières demandées lors d'un audit ISO 27001 ou d'un questionnaire de sécurité client.

Comment gérer les accès dans une procédure informatique ?

Appliquez le moindre privilège : chaque compte reçoit uniquement les droits nécessaires, sur un compte nominatif protégé par authentification multifacteur, et les droits sont retirés dès le changement de poste ou le départ. Les identifiants partagés rendent toute action non imputable — le coffre-fort de mots de passe et les comptes nominatifs sont la contrepartie.

Que faire en cas de fuite de données personnelles ?

Alertez immédiatement le DPO, gelez les accès concernés et documentez les faits. Une violation de données à caractère personnel doit être notifiée à la CNIL dans les 72 heures après en avoir pris connaissance (article 33 du RGPD), et les personnes concernées informées si le risque est élevé. L'exemple d'incident du modèle intègre ce point d'escalade.