SI vs Informatique - Évitez les erreurs de pilotage coûteuses

Ce qui relève du métier et ce qui relève de la technique

Je vois souvent des équipes parler de “l’informatique” alors qu’elles décrivent en réalité un circuit de validation, un flux de données ou une règle de gestion. C’est là que la confusion commence. Le premier niveau est celui de l’organisation: qui saisit quoi, dans quel ordre, avec quelles validations, pour produire quelle information utile. Le second niveau est celui de la mécanique technique: sur quels serveurs, avec quels réseaux, quels outils de sauvegarde, quels accès et quelles couches de sécurité.

Dans une PME, le système d’information de facturation peut inclure les règles de validation, le CRM, la base clients, l’archivage légal et les contrôles de cohérence. Le système informatique, lui, regroupe les postes de travail, le réseau, l’hébergement, les sauvegardes et les outils d’administration. Cette séparation est simple à formuler, mais elle devient stratégique dès qu’il faut arbitrer un budget ou analyser un incident. C’est précisément cette différence qui explique les erreurs de pilotage les plus coûteuses.

Pourquoi la confusion fait perdre du temps et de l'argent

Quand on mélange les deux plans, on finit presque toujours par traiter le symptôme au lieu de traiter la cause. On achète un outil plus puissant alors que le processus est mal conçu. On renforce l’infrastructure alors que les droits d’accès sont incohérents. On confond aussi le service rendu avec la machine qui l’exécute, ce qui fausse les priorités et les budgets.

J’observe trois effets très classiques. D’abord, les projets techniques sont lancés sans cadrage métier solide, ce qui crée des reworks coûteux. Ensuite, les indicateurs de pilotage restent trop bas niveau: on mesure le taux de disponibilité d’un serveur, mais pas le délai de traitement d’une commande ou la qualité des données client. Enfin, la responsabilité se dilue entre éditeur, infogérant, DSI et direction métier, alors qu’il faut au contraire un propriétaire clair pour chaque service critique.

Sur le plan réglementaire, le sujet n’est pas théorique. Comme le rappelle Service Public, toute entreprise qui traite des données personnelles est concernée par le RGPD, quelle que soit sa taille. Autrement dit, la manière de structurer le système d’information a des effets directs sur la conformité, la traçabilité et la capacité à répondre à un incident. Pour éviter ces angles morts, il faut d’abord rendre le périmètre visible.

Cartographier le périmètre sans perdre les processus clés

La meilleure cartographie n’est pas celle qui liste le plus d’équipements. C’est celle qui relie un besoin métier à ses données, ses applications, ses dépendances techniques et ses responsables. Je préfère toujours partir des flux réels plutôt que des organigrammes théoriques, parce que les incidents suivent les dépendances, pas les schémas de présentation.

Commencer par les processus critiques

Je pars en général de quatre ou cinq processus qui portent vraiment l’activité: vendre, livrer, facturer, recruter, supporter le client. Pour chacun, je note les données manipulées, les applications utilisées, les étapes manuelles, les points de validation et les partenaires impliqués. Cette vue métier permet de comprendre ce qui casserait réellement l’activité si le service tombait.

Relier chaque application à un responsable

Un outil sans propriétaire est un futur incident. Il faut distinguer le responsable métier, qui arbitre l’usage, et le responsable technique, qui garantit l’exploitation. Sur les services sensibles, j’ajoute souvent un niveau de criticité et des contraintes de reprise, avec deux repères simples: le RTO, c’est-à-dire le délai maximal acceptable pour remettre le service en route, et le RPO, c’est-à-dire la quantité maximale de données que l’on accepte de perdre.

Lire aussi : Next Gen Firewall - Ce qui change vraiment et comment l'adopter

Tracer les dépendances cachées

La plupart des surprises viennent des dépendances invisibles: un export Excel, une API vers un prestataire, une authentification centralisée, un stockage documentaire, une tâche planifiée, une licence qui expire. Une cartographie utile doit montrer ces liens. Sinon, on croit sécuriser une application alors qu’on laisse un maillon essentiel hors champ. Dans mes revues, je demande toujours: “si ce composant tombe, qu’est-ce qui s’arrête vraiment ?”

1. Identifier les processus critiques et les données qu’ils consomment.
2. Recenser les applications qui portent ces processus, y compris les outils SaaS et les solutions métier.
3. Lister les dépendances techniques comme l’authentification, le réseau, l’hébergement et les sauvegardes.
4. Attribuer un propriétaire métier et un propriétaire technique à chaque service important.
5. Réviser la cartographie à chaque changement majeur, pas seulement lors d’un audit.

Une fois ce périmètre posé, la sécurité devient un sujet de gouvernance, pas seulement d’outillage. C’est là que la cybersécurité change réellement la façon de piloter l’ensemble.

Ce que la cybersécurité change dans la gouvernance

La sécurité ne se limite pas à ajouter un pare-feu ou un antivirus. La CNIL rappelle que la protection des données repose sur des mesures techniques et organisationnelles adaptées au risque, et que l’on doit combiner un socle d’hygiène avec une vraie analyse des risques. C’est exactement ce que j’observe sur le terrain: les projets les plus solides sont ceux qui relient la sécurité aux usages, aux données et à la criticité métier.

L’ANSSI va dans le même sens avec son guide d’hygiène informatique, qui regroupe 42 mesures pour renforcer la sécurité d’un système d’information. Ce n’est pas une liste décorative. Les mesures qui changent réellement la donne sont souvent les plus simples à comprendre, mais les plus difficiles à maintenir dans la durée.

• Authentification multifacteur pour les accès sensibles, surtout les comptes administrateur et les accès distants.
• Gestion stricte des privilèges pour éviter qu’un utilisateur conserve plus de droits que nécessaire.
• Segmentation réseau pour empêcher une intrusion locale de se propager partout.
• Gestion des correctifs pour réduire la fenêtre d’exposition des systèmes et des logiciels.
• Sauvegardes 3-2-1, c’est-à-dire plusieurs copies, sur plusieurs supports, dont une copie hors ligne ou isolée.
• Journalisation et supervision pour repérer les comportements anormaux avant qu’ils ne deviennent des incidents majeurs.
• Tests de restauration pour vérifier que la sauvegarde fonctionne vraiment, et pas seulement qu’elle existe.

J’insiste sur un point que beaucoup sous-estiment: externaliser l’exploitation n’externalise pas la responsabilité. Si le prestataire héberge, administre ou supervise, l’organisation garde malgré tout la maîtrise du risque, du contrat, des accès, des preuves et du plan de reprise. Le PRA définit comment redémarrer après l’incident; le PCA maintient les activités essentielles pendant l’incident. Sans ces deux briques, la sécurité reste théorique.

Les erreurs les plus fréquentes sur le terrain

Les mêmes erreurs reviennent dans presque tous les secteurs. Elles ne sont pas spectaculaires, mais elles fragilisent durablement la qualité du système et la capacité de réaction de l’entreprise.

• Confondre disponibilité technique et continuité métier: un serveur peut être en ligne alors qu’un processus critique reste bloqué.
• Définir la sécurité trop tard: si l’on ajoute la conformité et les contrôles à la fin, on finit par bricoler des exceptions.
• Ne pas tester les restaurations: une sauvegarde non restaurable est une illusion de sécurité.
• Oublier les dépendances externes: API, sous-traitants, connecteurs et services cloud doivent être suivis comme des composants du SI à part entière.
• Laisser les accès vivre leur vie: les comptes orphelins et les droits trop larges sont une cause classique d’incident.
• Mesurer ce qui est facile au lieu de mesurer ce qui compte: le ticket IT est parfois mieux suivi que le délai de livraison client.

Le problème inverse existe aussi: une architecture techniquement propre peut rester mal gouvernée si personne ne sait qui décide, qui valide et qui arbitre. Le choix du mode d’exploitation vient alors comme une conséquence logique.

Quand internaliser, externaliser ou basculer vers le cloud

Je ne traite jamais le cloud ou l’infogérance comme des réponses magiques. Ce sont des modèles d’exploitation, pas des solutions à un manque de clarté métier. Le bon choix dépend du niveau de criticité, du besoin de contrôle, de la vitesse attendue, de la sensibilité des données et de la capacité interne à piloter le contrat.

Le bon critère n’est pas “qui héberge ?”, mais “qui maîtrise quoi, avec quelles preuves et quel niveau de risque accepté ?”. Quand cette réponse est claire, la discussion devient beaucoup plus saine. On ne mélange plus la qualité du service rendu, la solidité de l’infrastructure et la valeur métier produite.

Garder le pilotage au niveau du métier, sans perdre la maîtrise technique

Si je devais résumer ma méthode en une règle, ce serait celle-ci: je garde le pilotage au niveau du métier et je garde la preuve au niveau technique. Autrement dit, je relie chaque décision à un processus, chaque processus à une donnée, chaque donnée à une application, et chaque application à une infrastructure maîtrisée.

• Documenter le parcours complet d’un service critique, du besoin métier jusqu’aux composants techniques.
• Nommer un responsable métier et un responsable technique pour chaque service important.
• Fixer des objectifs de reprise clairs avec RTO et RPO, puis les tester.
• Vérifier régulièrement les accès, les sauvegardes et les dépendances, pas seulement lors d’un audit.
• Réévaluer les risques à chaque changement majeur: nouveau SaaS, nouvel hébergeur, nouvelle intégration, nouveau flux de données.

Cette discipline évite beaucoup de débats stériles. Elle permet d’expliquer un risque, de défendre un budget et de décider plus vite, parce que chacun sait désormais de quel niveau on parle: organisation, données, applications ou infrastructure. C’est exactement ce qui rend un système d’information lisible, robuste et crédible dans la durée.