Serveur propre ou cloud: une décision d'architecture, pas une croyance

Dans de nombreuses entreprises de taille moyenne, l’infrastructure informatique centrale tourne sur un serveur physique qui se trouve quelque part dans le bâtiment. Dans la chaufferie, dans les archives, parfois même dans les combles. Il a bien fonctionné longtemps, jusqu’au jour où ce n’était plus le cas.

La tentation d’acheter simplement le serveur suivant est forte. C’est généralement la mauvaise décision.

Ce que coûte vraiment un serveur en propre

L’achat n’est que la partie visible. Ce qui s’accumule réellement :

• Matériel : renouvelé tous les quatre à six ans
• Licences : système d’exploitation serveur, serveur de messagerie, logiciel de sauvegarde, de façon récurrente
• Maintenance : mises à jour, correctifs, redémarrages – quelqu’un doit s’en occuper
• Électricité et climatisation : une salle serveur a besoin de refroidissement, souvent en continu
• Risque de panne : que se passe-t-il si le serveur est hors service parce qu’un ventilateur lâche ?
• Conformité sécurité : stratégies de sauvegarde, reprise après sinistre, contrôles d’accès

Les fournisseurs cloud ont mieux résolu la plupart de ces points – non pas parce qu’ils sont plus intelligents, mais parce qu’ils optimisent pour des milliers de clients simultanément. Ce qui représente un investissement spécial pour un serveur en propre est un équipement standard chez un fournisseur cloud.

Quand la migration cloud est pertinente

Elle est pertinente quand au moins l’une des conditions suivantes s’applique :

• Le matériel doit être renouvelé. Quiconque doit de toute façon acheter du nouveau matériel devrait d’abord se demander s’il veut vraiment en acheter.
• Les collaborateurs travaillent de plus en plus en mobilité. Les connexions VPN vers un serveur en propre sont une béquille dont le coût augmente avec le nombre de télétravailleurs.
• Plusieurs sites partagent des données. Un serveur en propre est une construction locale ; dès lors que plusieurs sites entrent en jeu, le cloud devient structurellement supérieur.
• La messagerie pose régulièrement des problèmes. Les serveurs de messagerie en propre sont la source la plus fréquente de tickets informatiques dans les entreprises de taille moyenne. La messagerie cloud (Microsoft 365 ou Google Workspace) résout la majorité de ces problèmes structurellement, pas symptomatiquement.
• La stratégie de sauvegarde est floue. Quiconque ne peut pas expliquer à tout moment où ses données sont sauvegardées, combien de temps elles sont conservées et avec quelle rapidité elles peuvent être restaurées – la migration cloud est une bonne occasion de remettre cela à niveau.

Quand elle n’est pas pertinente

Elle n’est pas pertinente quand :

• Le secteur ou l’activité ne l’exige pas. Certains ateliers, certaines productions, certains bureaux de conseil fonctionnent parfaitement avec du matériel local et n’ont pas besoin de mise à l’échelle. Si la douleur est absente, aucune migration n’est nécessaire.
• La connectivité internet est instable. Quiconque se trouve dans un lieu isolé avec une connexion peu fiable devrait d’abord résoudre le problème de connectivité avant de déplacer des systèmes critiques vers le cloud. Une messagerie cloud qui tombe régulièrement est pire qu’une messagerie sur site qui fonctionne.
• Des exigences de conformité spécifiques existent, qui ne peuvent être satisfaites qu’en local. C’est rare dans le domaine des PME, mais cela existe dans certains secteurs réglementés.

Les trois questions avant la décision

Avant que quiconque prononce le mot “migration cloud”, trois questions doivent avoir une réponse :

1. Ce qui migre en premier. Messagerie, stockage de fichiers, téléphonie, comptabilité. Séquentiellement, pas en parallèle.
2. Qui conduit la migration. Les équipes internes ont rarement l’expérience requise. Des prestataires sont nécessaires, mais ils ont besoin de quelqu’un du côté client pour maintenir la supervision.
3. Ce qui reste sur site. Une migration cloud complète est rarement réaliste. Quels systèmes restent locaux, et comment se connectent-ils au cloud, c’est la question la plus intéressante.

Serveur en propre ne veut pas dire infrastructure en propre

Une contradiction apparente qui revient régulièrement : ici, je déconseille le serveur dans la chaufferie, ailleurs je recommande de faire tourner l’IA sur sa propre infrastructure pour que les données de l’entreprise restent en interne. Ce n’est pas une contradiction, c’est le même critère appliqué deux fois. La question n’est jamais “en propre ou externe”, mais : qui exploite de façon plus fiable, et qui contrôle les données.

Le vieux serveur dans les archives perd sur les deux axes. Il n’est ni exploité professionnellement ni particulièrement protégé, seulement familier. Les usages standard comme la messagerie et le stockage de fichiers relèvent donc d’un fournisseur spécialisé. En revanche, le savoir confidentiel de l’entreprise qu’une IA doit traiter appartient sous votre propre contrôle : sur une infrastructure dédiée, hébergée professionnellement et attribuée à votre entreprise.

Le plus grand malentendu

“Cloud” ne signifie pas “nous externalisons et n’avons plus à y penser”. Le cloud déplace la responsabilité, il ne l’élimine pas. Une entreprise qui avait une mauvaise architecture sur son serveur en propre aura une mauvaise architecture dans le cloud. Les devoirs sont les mêmes – ils s’exécutent simplement ailleurs.

L’avantage n’est pas moins de responsabilité. L’avantage, c’est que la responsabilité se déplace vers ce que vous devriez réellement faire : réfléchir à l’architecture plutôt que remplacer des ventilateurs.