Pannes du cloud : à quel point les PME dépendent-elles de leurs prestataires informatiques ?

Le cloud fait depuis longtemps partie de l’infrastructure de base de nombreuses PME. E-mail, comptabilité, salaires, traitement des commandes ou logiciels métiers complets ne fonctionnent aujourd’hui plus nécessairement sur un serveur installé dans l’entreprise, mais chez des prestataires spécialisés. Dans de nombreux cas, cette approche est judicieuse – et souvent plus sûre que de tout exploiter soi-même.

Mais ces dernières années ont également montré ce qui peut se passer lorsqu’un tel service devient soudainement indisponible.

Quatre incidents – quatre conséquences très différentes

Microsoft 365 : Le 31 août 2026, Exchange Online a été touché par une panne importante. Des utilisateurs ont notamment signalé des problèmes d’accès ainsi que d’envoi et de réception d’e-mails. Heise a rendu compte de l’incident et a renvoyé au numéro d’incident EX1464935 attribué par Microsoft. Pour de nombreuses entreprises, la perturbation a été relativement courte, mais elle a une nouvelle fois montré à quelle vitesse un service cloud quotidien peut devenir un goulet d’étranglement.

Blue Yonder : En novembre 2024, l’éditeur de logiciels Blue Yonder a été victime d’une attaque par rançongiciel. Ses solutions sont notamment utilisées pour les chaînes d’approvisionnement, la gestion des marchandises ainsi que la planification du personnel et des affectations. Chez Starbucks, les systèmes de planification des équipes et de saisie du temps ont été affectés ; certaines données nécessaires au traitement des salaires ont dû être gérées manuellement. Reuters a rendu compte des conséquences de l’attaque. Chez certains clients, les effets se sont prolongés pendant plusieurs semaines.

CDK Global : La dépendance est apparue encore plus clairement en juin 2024 chez le fournisseur américain CDK Global. Cette plateforme métier est utilisée par des milliers de concessionnaires automobiles pour la vente, l’atelier, le parc de véhicules, les données clients et d’autres processus commerciaux. Après une cyberattaque, des services centraux ont été fortement perturbés pendant environ deux semaines. Les concessionnaires ont dû recourir au papier, à Excel, au téléphone et à d’autres procédures manuelles. Ars Technica a documenté ces deux semaines de fonctionnement en mode dégradé et a fait état de plus de 15 000 sites de concessionnaires touchés.

Infoniqa / Sage Suisse : La Suisse a connu un cas comparable en 2025. Infoniqa, qui avait repris Sage Suisse en 2021, a été victime d’une cyberattaque début août. En Suisse, la solution ONE Start Cloud a notamment été touchée. Heise a indiqué que la solution cloud n’était pas utilisable; un lecteur avait signalé au magazine une panne de plus d’une semaine. Inside IT a ensuite écrit qu’Infoniqa faisait face aux conséquences depuis plus de deux semaines.

Le point commun : la panne du fournisseur devient le problème du client

Les quatre cas diffèrent fortement par leur cause, leur durée et les systèmes concernés. Leur point commun est ailleurs : pendant l’indisponibilité des services centraux, les clients ne pouvaient plus effectuer certaines tâches ou seulement au prix de détours importants.

Une perturbation technique chez le fournisseur peut donc très rapidement devenir un risque opérationnel pour le client.

Le cloud reste souvent la bonne solution pour les PME

Cela ne signifie pas que les PME devraient recommencer à exploiter elles-mêmes l’ensemble de leurs systèmes. Au contraire : des fournisseurs cloud professionnels peuvent souvent assurer l’infrastructure, les mises à jour, la surveillance, la redondance et les mesures de sécurité de manière plus efficace et plus économique qu’une petite entreprise disposant de ressources informatiques limitées.

Les solutions cloud sont donc judicieuses dans de nombreux cas et peuvent même être plus sûres qu’un environnement local mal entretenu. L’essentiel est toutefois de connaître les dépendances qui en résultent et de les gérer consciemment.

Combien de temps l’entreprise peut-elle se passer d’un service ?

Tous les systèmes n’ont pas la même criticité. Pour une entreprise artisanale, une panne d’e-mail de quelques heures, voire de plusieurs jours, peut être désagréable tout en restant supportable. Le travail peut continuer, les clients peuvent être joints par téléphone et un devis peut être envoyé plus tard si nécessaire.

Pour une autre entreprise, 24 heures sans e-mail peuvent déjà avoir de graves conséquences – par exemple lorsque des délais importants, des dépôts urgents ou une grande partie de la communication avec les clients en dépendent. Dans ce cas, il peut être judicieux de prévoir une solution de repli prête à l’emploi.

Une entreprise qui peut se passer d’un service pendant plusieurs jours, voire plus longtemps, n’a pas nécessairement besoin d’un système de remplacement immédiatement disponible. Elle devrait toutefois savoir à partir de quel moment elle veut passer au plan B – et combien de temps environ la mise en œuvre de ce plan prendra.

Ce deuxième délai est souvent oublié : si un système de remplacement nécessite cinq jours avant de pouvoir être utilisé en production, la décision de l’activer ne doit pas être prise seulement au cinquième jour de la panne.

Pour les ERP et les logiciels métiers, chaque jour peut compter

La situation est différente pour les systèmes qui sont alimentés chaque jour par de nombreux collaborateurs avec de nouvelles données commerciales. Dans un logiciel métier ou un ERP, des commandes, devis, heures de travail, factures, mouvements de matériel, données clients ou informations salariales sont créés en permanence.

Une seule journée de panne peut déjà obliger à ressaisir des informations, à contourner manuellement des processus ou à reconstruire ultérieurement des étapes de travail entières. Il est donc d’autant plus important de savoir combien de temps une telle panne est acceptable et quelles informations doivent être disponibles pour fonctionner en mode d’urgence.

Les données commerciales doivent rester accessibles à long terme

À la capacité de fonctionner à court terme s’ajoute une deuxième question : la disponibilité à long terme des données. En Suisse, certains documents – notamment les livres comptables et les pièces comptables – doivent être conservés pendant dix ans. Les documents conservés sous forme électronique doivent pouvoir être rendus lisibles à tout moment pendant cette période. Cela découle de l’art. 958f CO.

La question « Notre fournisseur cloud dispose-t-il d’une sauvegarde ? » ne suffit donc pas à elle seule. Les entreprises devraient également vérifier si leurs principales données commerciales peuvent rester disponibles indépendamment du fournisseur et si elles pourront réellement être réutilisées en cas d’urgence.

Et si le fournisseur ne revenait jamais ?

Qu’un fournisseur puisse disparaître durablement n’est pas un scénario purement théorique. En 2020, l’exploitant de centre de données Grapin Data Center, basé à Winterthour, a fait faillite. Les clients ont dû déplacer leurs systèmes ; à un moment donné, il était même question d’une possible coupure de courant du centre de données. Inside IT avait alors rendu compte de « l’évacuation » à court terme des infrastructures clients.

Une entreprise n’a même pas besoin de faire faillite pour disparaître. RapidShare en est un exemple : l’hébergeur de fichiers zougois figurait autrefois parmi les sites web les plus visités au monde. En 2015, l’entreprise a décidé d’arrêter le service actif. Les comptes restants ont ensuite été supprimés. Inside IT a rendu compte de la fin de cet hébergeur suisse.

Pour le client, la raison est finalement secondaire. Cyberattaque, faillite, retrait stratégique ou autre restriction : ce qui compte, c’est de savoir si les données et les processus de l’entreprise peuvent continuer à être utilisés lorsque le fournisseur d’origine n’est plus disponible.

Une sauvegarde indépendante est plus qu’une deuxième copie

Pour les systèmes cloud particulièrement importants, il peut donc être judicieux de sauvegarder également les données en dehors de la plateforme elle-même – par exemple chez un prestataire tiers indépendant ou sur une infrastructure séparée.

Il ne suffit pas de vérifier qu’une copie existe. Il est tout aussi important de savoir dans quel format les données sont disponibles et si elles peuvent être lues, analysées ou transférées vers une autre solution sans le système d’origine.

Une sauvegarde qui ne peut être restaurée que dans l’application devenue indisponible n’apporte qu’une autonomie limitée dans un tel scénario.

L’autonomie, c’est connaître ses dépendances

Une bonne stratégie cloud ne signifie donc pas renoncer au cloud ni dupliquer chaque système. Elle consiste à connaître les dépendances de l’entreprise et à prendre une décision consciente pour les plus importantes : combien de temps le service peut-il être indisponible ? Quand le plan B est-il activé ? Combien de temps sa mise en œuvre prend-elle ? Où se trouvent les données nécessaires – et restent-elles utilisables indépendamment du fournisseur ?

vNext aide les entreprises à rendre précisément ces dépendances et flux de données visibles : où se trouvent les données importantes, comment elles sont sauvegardées et comment elles peuvent continuer à être utilisées à long terme ou après la disparition d’un fournisseur.

Le cloud n’est pas le problème. La situation devient critique lorsqu’une entreprise ne découvre sa dépendance qu’après la panne du service.