Permissions et sauvegardes d’un système de gestion : ce que le dirigeant doit pouvoir vérifier

Deux questions suffisent pour savoir si un système de gestion est maîtrisé ou seulement allumé : qui voit quoi, et combien de travail est perdu si demain matin le système n’est plus là. Ce sont des questions de dirigeant, pas de technicien, et elles doivent être posées avant la signature, parce qu’après elles deviennent des demandes de modification à chiffrer.

Pour les vérifier, aucune compétence informatique n’est nécessaire. Il faut deux documents que n’importe qui peut lire : un tableau de qui peut faire quoi, et le procès-verbal d’un test de restauration réussi.

Les permissions ne sont pas une question de confiance

L’objection la plus courante est qu’en entreprise on fait confiance à tout le monde. Le point est ailleurs : les permissions limitent les dégâts des erreurs, des identifiants volés et des départs mal gérés, et permettent de reconstituer qui a fait une modification. Une personne honnête qui se trompe de ligne peut effacer un an de fiches exactement comme une personne malhonnête.

• Une permission se donne pour l’activité, pas pour la personne. Quand la fonction change, le rôle change, plutôt que d’ajouter une exception.
• Voir, modifier, supprimer et exporter sont des actions différentes. L’export est celle qu’on oublie, et c’est celle par laquelle les données sortent vraiment de l’entreprise.
• Certaines données ne sont pas utiles à ceux qui n’en ont pas besoin : coûts d’achat, marges, données du personnel, conditions confidentielles convenues avec des clients individuels.

La matrice rôles-actions

C’est le document qui rend la discussion concrète. Il s’écrit avec les responsables, puis se remet au fournisseur pour qu’il le réalise, pas l’inverse. Exemple illustratif pour une entreprise avec un stock, un service commercial et une administration.

La colonne qui sert vraiment est la dernière. Lister ce qu’un rôle ne doit pas pouvoir faire oblige à décider ; la liste de ce qu’il peut faire, seule, tend à gonfler jusqu’à ne plus rien vouloir dire.

Entre, change de département, sort : le cycle que personne ne maîtrise

Les permissions ne se dégradent pas le premier jour. Elles se dégradent en trois ans, une exception à la fois.

1. Arrivée : la personne reçoit le rôle prévu, pas la copie du compte d’un collègue. Copier un compte est le moyen le plus rapide de propager des privilèges que personne n’avait décidés.
2. Changement de fonction : on retire l’ancien rôle et on donne le nouveau. Additionner les deux est la cause principale des permissions accumulées.
3. Remplacements et délégations : ils ont une date de fin écrite, sinon ils restent.
4. Départ : l’accès se ferme le jour même, et la liste comprend aussi la messagerie, les archives partagées, les appareils et les comptes de services externes.

Sauvegardes : deux chiffres à convenir, pas une simple assurance

À la question « y a-t-il des sauvegardes ? », la réponse est toujours oui. La bonne question comporte deux volets, et tous deux relèvent de vos décisions avant d’être techniques.

• Combien de travail pouvez-vous vous permettre de perdre. Si la sauvegarde est nocturne, une panne à 17 heures coûte une journée de saisies. Si une journée est insoutenable, la fréquence doit être augmentée, et cela a un coût à comparer à celui de la perte.
• Combien de temps pouvez-vous rester à l’arrêt. Remettre un système sur pied demande des heures, pas des minutes, et la durée dépend de ce qui a été préparé à l’avance.

Les deux valeurs doivent être écrites dans le contrat, avec ce qu’elles comprennent. Un exemple illustratif, avec des chiffres à décider au cas par cas : sauvegardes quotidiennes conservées pendant quelques semaines, une sauvegarde périodique conservée plus longtemps, et au moins une copie dans un lieu différent, inaccessible avec les mêmes identifiants que les systèmes en usage.

• Ce qui est sauvegardé : la base de données, mais aussi les pièces jointes, les documents générés, les configurations et les personnalisations. Une restauration de la seule base de données peut laisser de côté des années de documents.
• Qui contrôle que les sauvegardes sont vraiment réalisées et qui est prévenu quand elles échouent. Une sauvegarde qui échoue en silence est la situation la plus courante et la plus dangereuse.
• Qui peut accéder aux sauvegardes : elles contiennent les mêmes données que le système, avec les mêmes obligations de confidentialité.

Une restauration non testée n’existe pas

La seule preuve qu’une sauvegarde fonctionne, c’est de l’avoir remise sur pied. Le test se fait sur un environnement séparé, avec des données de démonstration ou une copie, et il fait l’objet d’un procès-verbal. Le procès-verbal est le document que vous pouvez demander chaque année sans discuter de technologie.

1. Date du test, qui l’a exécuté et sur quelle sauvegarde.
2. Ce qui a été restauré : système, base de données, pièces jointes, configurations.
3. Combien de temps a été nécessaire, du feu vert au système de nouveau utilisable.
4. Ce qui a été vérifié ensuite : quelques documents ouverts, quelques fiches contrôlées, une impression réalisée, un accès testé avec un utilisateur normal.
5. Ce qui n’a pas fonctionné et comment cela a été corrigé. Un premier test sans aucun problème relevé a généralement été fait de façon trop facile.

Ce qu’on ne peut pas promettre

Aucun fournisseur ne peut garantir qu’un système ne sera jamais piraté ou que des données ne seront jamais perdues. Celui qui le promet vend de la tranquillité, pas de la sécurité.

Ce que ce guide ne couvre pas

Ici, il est question d’exigences vérifiables sur les accès et la récupération : aucune garantie absolue de sécurité et aucune déclaration de conformité. Les tests fonctionnels à faire avant de mettre un logiciel en usage, c’est-à-dire vérifier qu’il fait ce qui est nécessaire sur des cas réels, sont autre chose et viennent avant. La façon d’éviter de rester lié à un seul fournisseur, avec des données et des identifiants qui doivent rester les vôtres, mérite elle aussi un développement à part.