Décommissionnement

Retrait définitif d’un système : la dernière étape de son cycle de vie

Éteindre n’est pas supprimer

Un serveur qu’on éteint sans faire le reste n’est pas décommissionné : il est en pause, avec ses droits, ses comptes et ses données intacts. Il suffit qu’on le rallume, pour un essai ou par erreur, pour qu’il reprenne sa place dans le réseau tel qu’il était le jour de son arrêt, sans les mises à jour publiées depuis. Il en va de même d’une machine virtuelle arrêtée ou d’un abonnement cloud laissé en sommeil.

Ce qui survit presque toujours

Les comptes de service créés pour l’occasion, l’entrée DNS qui continue de pointer quelque part, le certificat renouvelé automatiquement, la tâche planifiée qui s’exécute dans le vide, les sauvegardes qui contiennent encore toute la base. Chacun de ces restes est invisible dans l’usage quotidien et parfaitement visible pour qui cherche : c’est de la surface d’attaque que plus personne ne surveille, parce que le système, officiellement, n’existe plus.

Un sujet de conformité autant que de technique

Tant que des données personnelles subsistent — dans une base, un export, une sauvegarde — le traitement continue, même si l’application est arrêtée. Il reste donc dans le registre des activités de traitement et soumis à sa durée de conservation. Un décommissionnement mené jusqu’au bout est ce qui permet de rayer une ligne de ce registre honnêtement.

Ce qui fait qu’il a vraiment eu lieu

Quatre réponses écrites : à quelle date, par qui, ce qui a été conservé et jusqu’à quand, et ce qui a été détruit. C’est court, et c’est ce qui manque dans la quasi-totalité des cas. Considérer la sortie d’un système comme une étape à part entière, planifiée comme sa mise en service, est ce qui distingue un parc que l’on connaît d’un parc dont on a hérité.

Mise à jour : 27 septembre 2026