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.
Votre téléchargement a commencé.
Pas de démarrage ? Réessayer le fichier Word ou obtenir le PDF.
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 / outil | Usage | Responsable | Criticité |
|---|---|---|---|
| {{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
| Terme | Dé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ôle | Responsabilité |
|---|---|
| {{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)
| Étape | Action | Responsable | Ré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
| Anomalie | Que faire | Escalade 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
| Version | Date | Auteur | Ré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
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 / outil | Usage | Responsable | Criticité |
|---|---|---|---|
| Site de vente | Commandes clients | Équipe produit | Critique |
| API de paiement | Encaissement | Équipe paiement | Critique |
| Supervision et alertes | Détection des incidents | Exploitation | Élevée |
| Gestion des identités (SSO/MFA) | Accès aux consoles d'administration | IT / sécurité | Critique |
4.Définitions et abréviations
| Terme | Définition |
|---|---|
| P1 / P2 / P3 | Niveaux de gravité, du plus critique au moins critique |
| Astreinte | Salarié joignable hors horaires pour intervenir sur un incident |
| Post-mortem | Analyse écrite après incident, sans recherche de responsable individuel |
Niveaux de gravité et délais de prise en charge
| Gravité | Définition | Prise en charge | Information |
|---|---|---|---|
| P1 — critique | Service indisponible ou données exposées | Immédiate, astreinte activée | Direction et clients sous 1 h |
| P2 — majeure | Fonction dégradée, contournement possible | Sous 2 h ouvrées | Responsables métier |
| P3 — mineure | Gêne limitée, sans impact métier | Prochain jour ouvré | Demandeur uniquement |
5.Rôles et responsabilités
| Rôle | Responsabilité |
|---|---|
| Technicien d'astreinte | Qualifie l'incident, applique le contournement et tient le journal |
| Responsable d'exploitation | Décide de l'escalade et pilote la communication |
| Directeur des systèmes d'information | Informe 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)
| Étape | Action | Responsable | Résultat attendu |
|---|---|---|---|
| 1 | Accuser réception de l'alerte et ouvrir le journal d'incident | Technicien d'astreinte | Incident enregistré avec horodatage |
| 2 | Qualifier la gravité (P1/P2/P3) selon le tableau | Technicien d'astreinte | Gravité tracée et délais engagés |
| 3 | Appliquer le contournement ou le retour arrière | Technicien d'astreinte | Service rétabli ou impact réduit |
| 4 | Informer les parties prenantes selon la gravité | Responsable d'exploitation | Message envoyé dans le délai prévu |
| 5 | Vérifier le rétablissement par la supervision | Technicien d'astreinte | Indicateurs revenus à la normale sur 30 minutes |
| 6 | Clôturer et planifier le post-mortem sous 5 jours ouvrés | Responsable d'exploitation | Post-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
| Anomalie | Que faire | Escalade vers |
|---|---|---|
| Aucune réponse de l'astreinte sous 15 minutes | Escalader au niveau suivant de l'annuaire | Responsable d'exploitation |
| Suspicion de fuite de données personnelles | Alerter immédiatement le DPO et geler les accès concernés | Directeur des systèmes d'information |
| Le retour arrière échoue | Basculer sur le plan de continuité et convoquer la cellule de crise | Responsable 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
| Version | Date | Auteur | Résumé de la modification |
|---|---|---|---|
| 1.0 | 1er juin 2026 | Responsable d'exploitation | Première diffusion |
13.Approbation
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
- Consultez la procédure informatique complète, avec l'exemple d'incident de production.
- Téléchargez-la en Word (.docx) ou PDF, ou copiez le texte pour Google Docs.
- 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.