Logiciel local ou cloud : quelle sécurité en 2026 ?

7 h 12. Les premiers chevaux sortent. Une salariée ouvre les soins sur son téléphone. Au bureau, il faut retrouver un contrat. Puis Internet coupe.

Avec un logiciel 100 % cloud, le travail dépend d’un serveur distant et du chemin qui y mène. Avec un logiciel local-first, les données utiles au travail vivent d’abord sur les appareils autorisés. Le cloud peut synchroniser, sauvegarder ou relayer, mais il n’est plus nécessaire pour chaque action.

Cette différence change la disponibilité. La sécurité dépend aussi des copies conservées côté serveur et des personnes qui peuvent les lire. Une base locale chiffrée ne rend pas une copie synchronisée illisible pour le fournisseur : une intrusion chez celui-ci peut encore atteindre plusieurs structures.

Cela ne signifie pas que « local » veut automatiquement dire « inviolable », ni que tout cloud est mal sécurisé. Un ordinateur mal protégé peut être volé, infecté ou détruit. Un fournisseur cloud sérieux peut disposer d’équipes, de sauvegardes et d’une surveillance difficiles à égaler en interne.

La bonne question est donc plus précise : où la donnée existe-t-elle en clair, qui contrôle les clés, et combien de structures une seule compromission peut-elle exposer ?

Quelle différence entre cloud, local et local-first ?

Un logiciel 100 % cloud, ou SaaS, s’utilise généralement dans un navigateur ou une application connectée. Les données métier sont envoyées vers l’infrastructure du fournisseur. Le serveur les stocke et, le plus souvent, les traite pour afficher les dossiers, lancer une recherche, produire une facture ou calculer un planning.

Un logiciel local est installé sur un appareil. Il peut enregistrer ses données sur cet appareil et continuer à fonctionner sans réseau. Mais le mot « local » ne dit rien, à lui seul, sur le chiffrement, les sauvegardes ou les mises à jour.

Un logiciel local-first combine les deux mondes. L’appareil conserve une copie locale exploitable, tandis qu’un service distant assure certaines fonctions comme la synchronisation entre appareils. La conception donne la priorité au fonctionnement local ; le réseau devient une amélioration, pas une condition permanente.

L’apparence du logiciel ne suffit donc pas à révéler son architecture. Une application mobile peut conserver une véritable base locale. À l’inverse, un logiciel installé peut dépendre entièrement d’un serveur distant.

Le modèle cloud classique

Dans un SaaS classique, le serveur central est la source principale de vérité. Cette centralisation facilite l’accès depuis n’importe quel appareil, les mises à jour immédiates et la collaboration. Elle simplifie également l’administration pour le client.

En contrepartie, le fournisseur concentre les comptes, les données et les autorisations de nombreuses organisations. Son infrastructure, ses employés, ses sous-traitants, ses sauvegardes et ses interfaces d’administration entrent tous dans le périmètre de confiance.

Le modèle local-first

Dans un modèle local-first, chaque structure possède sa base de travail sur ses appareils autorisés. La synchronisation transporte les changements entre eux, mais l’activité quotidienne ne doit pas attendre une réponse du cloud.

La sécurité dépend de chaque appareil, des services de synchronisation et des copies hébergées. Certains produits chiffrent les contenus avant leur envoi en gardant les clés sur les appareils ; d’autres doivent pouvoir les lire pour les traiter. Le fonctionnement local ne permet pas à lui seul de déduire quel modèle est utilisé.

Pourquoi le cloud 100 % centralise-t-il le risque ?

La centralisation est efficace. C’est précisément pour cela qu’elle attire : une seule porte peut mener à beaucoup de données.

Le rapport annuel 2025 de la CNIL fournit un exemple particulièrement parlant. L’organisme a reçu 17 802 notifications de violations de données. Mais deux incidents ayant touché deux éditeurs de logiciels ont, à eux seuls, provoqué 11 635 notifications de leurs clients. Pour analyser la tendance sans compter plusieurs fois les mêmes incidents sources, la CNIL a retenu un total ajusté de 6 167 violations, soit 9,5 % de plus qu’en 2024. Une violation sur deux relevait d’un piratage et une quarantaine concernaient plus d’un million de personnes.

Ce chiffre ne prouve pas que tous les éditeurs cloud sont vulnérables. Il illustre le rayon d’impact d’une architecture mutualisée : compromettre un prestataire peut obliger des milliers de clients à déclarer les conséquences du même événement.

Le piratage de la Direction générale des Finances publiques (DGFiP) révélé en août 2026 montre ce que cette concentration peut représenter avec des données fiscales particulièrement détaillées. Les investigations ont établi que des accès illégitimes, obtenus par usurpation d’identifiants, avaient permis de consulter ou d’extraire des données concernant 678 000 particuliers et professionnels. Parmi elles figuraient notamment le revenu fiscal de référence, le quotient familial, le taux de prélèvement à la source, ainsi que des adresses et surfaces cadastrales.

L’Éducation nationale illustre la même logique. Le ministère a confirmé le 31 juillet 2026 qu’un compte professionnel usurpé avait donné accès à son système de formation des personnels. Les données susceptibles d’avoir été exfiltrées concernent des agents ayant exercé en académie depuis 2001 : identité, statut, fonctions et, pour certains, adresse, téléphone et numéro de sécurité sociale. Le 18 août, le ministère indiquait encore expertiser des publications revendiquant aussi des données d’élèves, sans en confirmer le périmètre exact.

Ces incidents ne signifient pas qu’un service public centralisé ou qu’un cloud est condamné à être piraté. Ils matérialisent le rayon d’impact : un seul accès compromis peut exposer, en une opération, des informations très précises appartenant à un grand nombre de personnes. Une architecture compartimentée cherche précisément à éviter qu’une compromission unique ouvre un périmètre aussi large.

L’objectif n’est pas de transformer cet article en inventaire de toutes les fuites. Pour suivre les incidents français au fil de l’eau, French Breaches tient un annuaire indépendant qui distingue notamment les fuites confirmées des revendications encore à vérifier.

L’ANSSI observe également que les environnements cloud sont de plus en plus ciblés, à la fois pour la valeur des données hébergées et parce qu’ils peuvent servir de point d’entrée vers les systèmes de leurs clients.

Une panne ou une attaque devient collective

Dans une architecture centralisée, plusieurs événements peuvent interrompre simultanément le travail de tous les clients :

une indisponibilité du fournisseur ;
une erreur de configuration ou de déploiement ;
le vol d’un compte administrateur ;
une faille dans une API mutualisée ;
une attaque par rançongiciel ;
la compromission d’un sous-traitant ou d’une chaîne logicielle.

La qualité de l’hébergeur ne supprime pas cette propriété. Un hébergement français peut apporter des garanties utiles de localisation, de droit applicable et de maîtrise des transferts. Il ne démontre pas que le fournisseur ne peut pas lire les données, ni que les clés sont contrôlées exclusivement par le client.

Souveraineté géographique et confidentialité cryptographique sont deux questions différentes.

Le chiffrement cloud protège-t-il vraiment les données ?

Oui, mais il faut demander quel chiffrement, à quel moment et avec quelles clés.

Le chiffrement en transit, généralement assuré par HTTPS/TLS, protège les échanges entre l’appareil et le serveur. Il empêche un tiers sur le réseau de lire facilement le trafic. Une fois arrivé, le serveur déchiffre toutefois la requête pour la traiter.

Le chiffrement au repos protège les disques, les volumes ou les sauvegardes du fournisseur. Il est essentiel en cas de perte physique d’un support. Mais si le serveur ou son gestionnaire de clés peut déchiffrer automatiquement la base, un attaquant ayant obtenu les mêmes privilèges peut potentiellement faire de même.

La CNIL distingue clairement ces modèles. Lorsqu’un service SaaS doit exécuter des traitements sur les données, celles-ci sont habituellement disponibles en clair au moment du calcul. Le chiffrement côté serveur protège donc certains scénarios, sans empêcher nécessairement le prestataire ou un attaquant privilégié d’accéder au contenu.

Le chiffrement côté client change la frontière de confiance

Avec un chiffrement côté client, les données sont chiffrées sur l’appareil avant leur envoi. Si les clés restent sous le contrôle des appareils autorisés, le serveur reçoit un contenu qu’il peut conserver ou relayer sans savoir le lire.

Le chiffrement de bout en bout ajoute une propriété : seuls les terminaux aux extrémités de l’échange disposent des clés nécessaires au déchiffrement. Le serveur intermédiaire transporte le message, mais ne constitue pas une extrémité de confiance.

Cette architecture limite l’effet d’une fuite de stockage. L’attaquant peut encore voler des blobs chiffrés, des métadonnées techniques ou perturber le service. Il ne devrait pas pouvoir transformer les blobs métier en dossiers lisibles sans compromettre également une clé ou un appareil autorisé.

Le mot « chiffré » sur une page commerciale ne suffit donc pas. Il faut demander :

les données sont-elles chiffrées uniquement sur le disque du serveur ?
sont-elles déchiffrées par le fournisseur pour chaque traitement ?
qui détient et administre les clés ?
une personne ayant les droits d’administration du cloud peut-elle consulter un dossier client ?
une compromission du serveur suffit-elle à lire les sauvegardes ?

Que change une architecture locale et chiffrée ?

Une base locale chiffrée protège la copie conservée sur l’appareil et facilite le travail sans réseau. Elle ne protège pas automatiquement les copies serveur. Le rayon d’impact d’une intrusion dépend des données hébergées, de leur lisibilité et des droits compromis.

La protection d’un poste et celle du service distant restent donc complémentaires. Un attaquant peut viser l’appareil, un compte autorisé ou le fournisseur qui traite les copies synchronisées.

Architecture d’un logiciel cloud classique où les données métier vivent sur le serveur

La donnée reste utile sans Internet

Le premier bénéfice est la disponibilité. Une coupure de fibre, une zone blanche ou une panne du fournisseur n’empêche pas d’ouvrir les données déjà présentes sur l’appareil. Le logiciel et le mobile peuvent continuer à enregistrer le travail, puis synchroniser lorsque le réseau revient.

Cette résilience ne constitue pas seulement un confort. Dans une structure équestre, les soins, les rations, les mouvements de chevaux et les informations opérationnelles ne peuvent pas attendre le rétablissement d’un site distant.

Le vol du serveur n’est plus le même événement

Si le serveur de synchronisation ne possède que des contenus chiffrés côté client, son piratage reste sérieux : disponibilité, comptes, métadonnées, journaux techniques ou fonctions non chiffrées peuvent être concernés. Mais il ne doit pas suffire à rendre lisibles les données métier protégées de toutes les structures.

Cette protection dépend d’un chiffrement réellement effectué avant l’envoi et de clés que le serveur ne possède pas. Elle ne s’applique pas à un service qui héberge et traite les données lisibles, comme la synchronisation actuelle de GlysOS.

L’intelligence artificielle change-t-elle la menace ?

Oui, surtout par la vitesse, l’échelle et l’automatisation. L’intelligence artificielle ne crée pas magiquement des failles dans tous les services. Elle aide cependant des attaquants à rechercher des surfaces exposées, écrire ou adapter du code, analyser des systèmes et enchaîner des actions beaucoup plus rapidement.

Entre mars 2025 et mars 2026, Anthropic indique avoir banni 832 comptes associés à des activités cyber malveillantes ou abusives. Les cas observés couvraient les 14 tactiques du référentiel MITRE ATT&CK et près de 13 900 actions. La part des acteurs évalués à risque moyen ou élevé est passée de 33 % à 56 % sur la période étudiée.

Anthropic a aussi documenté en 2025 une campagne d’espionnage orchestrée par une IA. Selon l’entreprise, l’opération a ciblé environ trente entités, dont de grandes entreprises technologiques et des organismes gouvernementaux. L’agent aurait exécuté 80 à 90 % des opérations tactiques, avec quelques intrusions réussies. Des hallucinations limitaient encore son autonomie, mais le niveau d’automatisation constitue un changement d’échelle.

OpenAI a rapporté de son côté qu’un agent utilisant notamment GPT-5.6 Sol avait compromis l’infrastructure de Hugging Face pendant une évaluation de sécurité interne. Ce cas doit être interprété avec précision : les garde-fous cyber avaient été réduits pour le test et il ne décrit pas l’usage ordinaire d’un chatbot public. Il montre néanmoins que les modèles avancés sont capables d’enchaîner des opérations offensives réelles dans certaines conditions.

Le coût d’une attaque baisse

Ces capacités peuvent rendre rentables des attaques qui ne l’étaient pas auparavant. Un acteur peut tester davantage de cibles, adapter ses tentatives et exploiter plus vite une faiblesse nouvellement publiée.

Le Panorama de la cybermenace 2025 de l’ANSSI comptabilise 3 586 événements de sécurité traités, dont 1 366 incidents. L’agence souligne notamment la progression des exfiltrations de données.

Il serait donc imprudent de promettre que le nombre de violations « va forcément exploser » selon un pourcentage précis. En revanche, il est raisonnable de considérer que l’automatisation augmente la pression sur chaque service exposé et accélère la découverte comme l’exploitation des erreurs.

Dans ce contexte, limiter les droits, séparer les accès et réduire les données exposées reste essentiel, sur chaque poste comme dans les services mutualisés.

Un logiciel local est-il automatiquement plus sûr ?

Non. Le local-first transforme le risque ; il ne dispense pas des règles de sécurité.

Un poste non mis à jour peut être infecté. Un mot de passe faible peut être deviné. Une session laissée ouverte peut être utilisée. Un rançongiciel peut chiffrer la base locale et les fichiers connectés. Un disque peut tomber en panne. Sans sauvegarde, la maîtrise locale peut se transformer en perte locale.

Une étude 2025 de Cybermalveillance.gouv.fr, menée auprès de 588 TPE-PME, indique que 16 % avaient déclaré au moins un incident cyber au cours des douze mois précédents. Parmi les causes identifiées figuraient notamment l’hameçonnage, l’exploitation de vulnérabilités et la compromission de sites Internet.

Une sauvegarde connectée n’est pas une sauvegarde suffisante

Le fonctionnement hors ligne et la sauvegarde hors ligne sont deux notions différentes. Une application peut fonctionner sans Internet tout en enregistrant ses sauvegardes sur un disque constamment branché. Un rançongiciel pourrait alors atteindre la base active et sa copie.

Cybermalveillance.gouv.fr recommande de déconnecter les supports de sauvegarde lorsqu’ils ne sont pas utilisés. Une stratégie robuste prévoit plusieurs copies, au moins un support isolé, des restaurations testées et des droits d’accès limités.

Les appareils deviennent une frontière de sécurité

Le local-first exige donc :

un chiffrement réel de la base locale ;
un verrouillage fort des appareils et des sessions ;
des mises à jour régulières du système et du logiciel ;
des sauvegardes testées, dont une copie déconnectée ;
une authentification multifacteur pour les comptes distants ;
des droits adaptés au rôle de chaque utilisateur ;
une capacité de révocation lorsqu’un appareil est perdu.

Un cloud bien administré peut être plus sûr qu’un ordinateur local abandonné sans mises à jour ni sauvegardes. La comparaison pertinente oppose donc des architectures correctement mises en œuvre, pas leurs caricatures.

Quel modèle résiste le mieux à chaque incident ?

Incident	Logiciel 100 % cloud	Application avec copie locale et synchronisation
Coupure Internet	Accès souvent interrompu	Travail local maintenu, synchronisation différée
Panne du fournisseur	Peut toucher tous les clients	Les fonctions locales restent disponibles
Intrusion sur le serveur	Risque collectif élevé si les données ou clés y sont lisibles	Les copies serveur peuvent être exposées si elles sont lisibles ; le chiffrement local ne les protège pas
Vol d’un ordinateur	Données locales limitées si rien n’est conservé, mais session et jetons à protéger	Base exposée à l’attaque locale, avec protection assurée par le chiffrement et le verrouillage
Rançongiciel sur un poste	Peut atteindre les fichiers synchronisés et les identifiants	Peut atteindre la copie locale ; restauration et sauvegarde isolée indispensables
Compte administrateur du fournisseur compromis	Peut ouvrir un large périmètre selon les droits et le modèle de clés	Peut exposer les données synchronisées selon les permissions et la protection du service
Destruction d’un appareil	Données centrales généralement disponibles	Récupération possible si la synchronisation ou une sauvegarde saine existe
Mise à jour de sécurité	Centralisée et immédiate côté serveur	Doit être installée sur les applications et appareils concernés

Le cloud conserve de vrais atouts : redondance, supervision centralisée, déploiement rapide des correctifs et mutualisation d’expertise. La copie locale apporte une continuité hors ligne pour les fonctions prévues. Les garanties de confidentialité dépendent séparément du chiffrement et des accès aux copies locales et distantes.

Le meilleur choix dépend des données, des usages et de la mise en œuvre. Il faut vérifier séparément le chiffrement de la base locale, les traitements serveur, les permissions, les sauvegardes et la protection des appareils, sans déduire les uns des autres.

Comment GlysOS associe-t-il travail local et services cloud ?

GlysOS est conçu comme un logiciel installé, avec le poste de travail comme outil principal et le mobile comme compagnon de terrain. Les deux peuvent conserver leurs données localement et poursuivre les opérations prévues sans connexion permanente.

Desktop conserve une base locale chiffrée avec SQLCipher. Les données métier, historiques, documents et fichiers synchronisés sont également hébergés et traités par les services GLYS sous une forme lisible par le serveur. Le moteur hébergé peut utiliser SQLite sans chiffrement local de sa base. Les connexions sécurisées et les protections de stockage sont distinctes d’un chiffrement de bout en bout : cette garantie ne couvre pas la synchronisation actuelle.

L’architecture poursuit quatre objectifs :

continuer à travailler lorsque le réseau disparaît ;
conserver une copie locale pour les fonctions prévues sur les appareils ;
partager les données et fichiers par des connexions sécurisées ;
limiter les accès aux comptes, permissions et besoins des services autorisés.

Le détail de ces choix est présenté dans les pages Sécurité de GlysOS, logiciel équestre local ou cloud et logiciel équestre hors ligne.

Comment choisir sans croire les promesses marketing ?

Les expressions « hébergé en France », « conforme au RGPD », « données chiffrées » ou « cloud sécurisé » ne suffisent pas à comparer deux produits. Elles décrivent parfois une partie réelle du dispositif, mais rarement le modèle complet.

Avant de confier les dossiers de votre structure à un logiciel, demandez :

Où se trouve la copie de travail principale ? Sur l’appareil, sur un serveur ou sur les deux ?
Le logiciel fonctionne-t-il réellement sans Internet ? Quelles actions restent possibles et pendant combien de temps ?
Où les données existent-elles en clair ? Sur le poste, pendant leur traitement serveur, dans les journaux ou dans les sauvegardes ?
Qui contrôle les clés ? Le client, le fournisseur cloud ou un sous-traitant ?
Que verrait un attaquant ayant le contrôle du serveur ? Des dossiers lisibles, des clés, des blobs chiffrés ou seulement certaines métadonnées ?
Quel est le rayon d’impact d’une intrusion ? Une structure ciblée ou la base mutualisée de tous les clients ?
Comment restaurer après un incident ? Les sauvegardes sont-elles versionnées, isolées et régulièrement testées ?
Peut-on exporter les données dans un format exploitable ? La sécurité inclut la capacité à quitter un fournisseur sans perdre son historique.
Les droits sont-ils limités par rôle ? Chaque salarié doit accéder uniquement aux fonctions nécessaires.
Comment les incidents sont-ils détectés et notifiés ? Un dispositif de réponse compte autant que les protections préventives.

Le RGPD, dans son article 32, demande des mesures adaptées au risque : confidentialité, intégrité, disponibilité, résilience, restauration et tests réguliers. Il n’impose pas une architecture unique. Il oblige à comprendre celle que l’on choisit.

FAQ

Un logiciel cloud est-il moins sécurisé qu’un logiciel local ?

Pas automatiquement. Un cloud bien administré dispose souvent d’une excellente redondance et d’une surveillance professionnelle. Il concentre toutefois les données et les accès de nombreux clients. Une copie locale facilite le travail sans réseau, mais ne réduit pas à elle seule le rayon d’impact d’une intrusion serveur. Il faut examiner aussi les données synchronisées, les permissions et les sauvegardes.

Héberger les données en France suffit-il à les protéger ?

Non. L’hébergement en France peut améliorer la maîtrise juridique et la localisation des données. Il ne garantit pas que le fournisseur ne puisse pas les lire, que les clés lui échappent ou qu’une intrusion serveur soit sans conséquence. Il faut examiner le chiffrement et la gestion des clés.

Le chiffrement local protège-t-il aussi les copies synchronisées ?

Non. Le chiffrement de la base Desktop protège sa copie locale. Les données métier et fichiers synchronisés sont aussi hébergés et traités par les services GLYS sous une forme lisible par le serveur. Les connexions sécurisées et les contrôles d’accès protègent ces échanges ; le chiffrement local ne s’étend pas automatiquement aux copies serveur.

Que se passe-t-il si les serveurs de Glys sont piratés ?

Une compromission peut affecter la disponibilité et exposer les données métier et fichiers synchronisés, puisque les services GLYS les traitent sous une forme lisible. Le chiffrement de la base locale Desktop ne protège pas à lui seul ces copies serveur. Les contrôles d’accès, la protection de l’infrastructure et la réponse aux incidents restent nécessaires.

Que se passe-t-il si un ordinateur utilisant GlysOS est volé ?

La base locale sensible est chiffrée, ce qui oppose une protection au voleur. La sécurité dépend aussi du mot de passe, du verrouillage du système et de la capacité à révoquer l’appareil. Si le service de sauvegarde cloud est activé et qu’une copie récente a bien été effectuée, la perte de l’ordinateur n’entraîne pas celle des données : elles peuvent être restaurées sur une nouvelle machine depuis le parcours de récupération GlysOS. Aucun chiffrement ne remplace toutefois de bonnes pratiques sur le poste.

GlysOS fonctionne-t-il sans connexion Internet ?

Oui, les fonctions prévues localement continuent de s’appuyer sur les données présentes sur l’ordinateur ou le mobile. Les changements sont synchronisés lorsque la connexion revient. Certaines fonctions intrinsèquement distantes peuvent naturellement attendre le réseau.

Le local-first protège-t-il contre les rançongiciels ?

Il évite qu’une panne du cloud bloque automatiquement le travail, mais un rançongiciel présent sur l’appareil peut viser la base locale et les sauvegardes connectées. Une copie isolée, des mises à jour, des droits limités et des restaurations testées restent indispensables.

Sources vérifiées

Liens semantiques

[[memory/domain-map#Strategie, marque et commercial|Domaine : strategie et commercial]]