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é. Elle change aussi la sécurité. Dans un modèle centralisé, une intrusion chez le fournisseur peut atteindre un grand nombre de clients. Dans un modèle local-first correctement chiffré, l’attaquant doit se rapprocher de chaque structure et franchir des protections propres à ses appareils.

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 alors de deux périmètres complémentaires : la protection de chaque appareil et la protection du mécanisme de synchronisation. Si les données sont chiffrées avant de quitter l’appareil, le serveur n’a pas besoin de recevoir leur contenu métier lisible pour les relayer.

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 ?

Dans une architecture locale et chiffrée, la donnée métier exploitable vit d’abord sur l’appareil de la structure. Une attaque globale contre le fournisseur n’ouvre plus automatiquement la base lisible de tous ses clients.

Pour voler le contenu d’une écurie donnée, l’attaquant doit généralement cibler cette écurie : compromettre un ordinateur ou un mobile autorisé, récupérer les éléments de déverrouillage et contourner le chiffrement local. C’est possible, mais moins industrialisable qu’une extraction depuis une base centrale contenant tous les clients.

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.

Le risque n’est pas supprimé. Il est compartimenté. Au lieu d’une salle d’archives commune, chaque structure possède un coffre distinct et le transporteur manipule des colis fermés.

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, une architecture qui exige de compromettre séparément chaque structure oppose davantage de friction à l’attaquant qu’un point central donnant accès à des centaines ou des milliers de clients.

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	Logiciel local-first chiffré
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 blobs E2EE restent inexploitables sans les clés des appareils
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	Ne doit pas permettre de déchiffrer les contenus E2EE
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. Le local-first apporte d’autres garanties : continuité hors ligne, compartimentage et contrôle cryptographique plus proche du client.

Le meilleur choix dépend des données, des usages et de la mise en œuvre. Pour des informations métier sensibles consultées sur le terrain, l’association base locale chiffrée + synchronisation chiffrée de bout en bout + sauvegardes + discipline des appareils offre un équilibre particulièrement solide.

Pourquoi GlysOS choisit-il le local-first ?

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.

Les données locales sensibles sont stockées dans une base chiffrée. Les blobs de synchronisation documentés sont chiffrés de bout en bout avec XChaCha20-Poly1305 avant leur transport. La dérivation de clé s’appuie sur Argon2id. Le serveur de synchronisation relaie ces contenus sans posséder les clés métier nécessaires pour les lire.

L’architecture poursuit quatre objectifs :

1. continuer à travailler lorsque le réseau disparaît ;
2. conserver la donnée métier au plus près de la structure ;
3. chiffrer les flux de synchronisation avant leur départ ;
4. réduire ce qu’une compromission centrale peut exposer en une seule fois.

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 :

1. Où se trouve la copie de travail principale ? Sur l’appareil, sur un serveur ou sur les deux ?
2. Le logiciel fonctionne-t-il réellement sans Internet ? Quelles actions restent possibles et pendant combien de temps ?
3. Où les données existent-elles en clair ? Sur le poste, pendant leur traitement serveur, dans les journaux ou dans les sauvegardes ?
4. Qui contrôle les clés ? Le client, le fournisseur cloud ou un sous-traitant ?
5. 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 ?
6. Quel est le rayon d’impact d’une intrusion ? Une structure ciblée ou la base mutualisée de tous les clients ?
7. Comment restaurer après un incident ? Les sauvegardes sont-elles versionnées, isolées et régulièrement testées ?
8. Peut-on exporter les données dans un format exploitable ? La sécurité inclut la capacité à quitter un fournisseur sans perdre son historique.
9. Les droits sont-ils limités par rôle ? Chaque salarié doit accéder uniquement aux fonctions nécessaires.
10. 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. Un modèle local-first correctement chiffré réduit ce rayon d’impact, mais exige de sécuriser les appareils, les mises à jour 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.

Quelle différence entre chiffrement au repos et chiffrement de bout en bout ?

Le chiffrement au repos protège principalement le support de stockage. Le serveur peut généralement déchiffrer les données pour les traiter. Avec un chiffrement de bout en bout, les données sont chiffrées avant le transport et seules les extrémités autorisées possèdent les clés nécessaires pour les lire.

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

Une attaque peut toujours perturber la disponibilité ou exposer des comptes, métadonnées et éléments relevant de fonctions serveur. En revanche, la compromission du serveur ne doit pas suffire à lire les blobs de synchronisation chiffrés de bout en bout, car les clés métier restent sur les appareils autorisés.

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 la sauvegarde cloud chiffrée est activée 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

• CNIL — Rapport annuel 2025
• Le Monde — French taxpayers’ data stolen in hack of Finance Ministry
• Ministère de l’Éducation nationale — Incident de sécurité affectant les données de personnels
• Ministère de l’Éducation nationale — Point de situation du 18 août 2026
• French Breaches — Annuaire indépendant des fuites de données en France
• ANSSI — Panorama de la cybermenace 2025
• ANSSI — État de la menace sur le cloud computing
• CNIL — Les pratiques de chiffrement dans le cloud public
• Cybermalveillance.gouv.fr — Maturité cyber des TPE-PME en 2025
• Anthropic — Mapping AI-enabled cyber threats
• Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign
• OpenAI — Hugging Face model evaluation security incident

Liens semantiques

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