Conseils et retours de terrain

Guides

Logiciel d'interventions souverain : 6 critères clés

Hébergement, base dédiée, réversibilité, API : 6 critères vérifiables pour un logiciel d’interventions souverain dans votre cahier des charges.

Un cahier des charges dont les six critères de souveraineté se cochent un à un, scellés par un écusson, avec la pastille de l'hébergement de G-ordonCahier des charges1Hébergement, sauvegardes2Lois extraterritoriales3Isolation des données4Réversibilité5Interopérabilité6Continuité hors ligneProduction en France, sauvegarde de secours dans l'UE

Le 10 septembre 2026, l’État a signé avec la filière numérique française le Pacte Numérique et IA. L’objectif affiché : faire de l’État un acheteur exigeant de solutions performantes, sécurisées et souveraines (InCyber). Le pacte ne crée pourtant aucune préférence nationale dans les marchés publics. Les principes de liberté d’accès, d’égalité de traitement et de mise en concurrence s’appliquent toujours (Code Confiance).

Pour un bailleur social, une collectivité ou une régie d’eau qui achète un logiciel de gestion des interventions, la souveraineté ne peut donc pas tenir dans une case « solution française ». Elle doit se traduire en critères vérifiables, liés à l’objet du marché et proportionnés. Voici les six critères que nous recommandons d’inscrire dans un cahier des charges FSM, avec la façon de les contrôler.

Pourquoi la souveraineté concerne aussi les interventions terrain

Un logiciel FSM ne se résume pas à un planning. Il centralise des données sensibles :

  • des données personnelles : noms, téléphones et adresses des locataires ou des abonnés, créneaux de présence, photos prises dans les logements ;
  • des données patrimoniales : localisation des équipements, plans de réseaux, historique des pannes et des contrôles réglementaires ;
  • des données d’exploitation : temps passés, matériels posés, preuves de passage, signatures.

Ces données servent à justifier une facturation, à répondre à une réclamation et à piloter un contrat de délégation. Elles alimentent aussi les plans pluriannuels d’entretien. Le jour où l’outil change de mains ou d’hébergeur, ou que le contrat prend fin, la question n’est plus théorique.

Les 6 critères à inscrire dans votre cahier des charges

1. Localisation de l’hébergement et des sauvegardes

Demandez où sont hébergées les données de production et les sauvegardes, et pas seulement « les serveurs ». Faites préciser l’hébergeur, les centres de données et la localisation des copies de secours. Une réponse vague (« en Europe ») ne suffit pas pour un acheteur public soumis au RGPD et à ses propres engagements envers les locataires ou les usagers.

Comment le vérifier : une annexe d’hébergement nominative (hébergeur, région, centres de données) intégrée au contrat ou à l’accord de traitement des données.

2. Exposition aux lois extraterritoriales

La localisation physique ne fait pas tout. Si l’éditeur ou son hébergeur relève d’un droit étranger qui permet d’exiger l’accès aux données, comme le CLOUD Act américain, le risque juridique subsiste même avec des serveurs en France. Le critère porte donc sur la chaîne de contrôle : éditeur, hébergeur et sous-traitants ultérieurs.

Comment le vérifier : la liste exhaustive des sous-traitants ultérieurs au sens du RGPD, avec leur pays d’établissement et leur rôle (hébergement, envoi de SMS, cartographie, supervision, etc.).

3. Isolation des données entre clients

Dans un SaaS, vos données côtoient celles d’autres organisations. Selon l’architecture, elles sont séparées par un simple identifiant dans une table commune ou par une base de données dédiée. Le second modèle limite le risque de fuite entre clients et simplifie les sauvegardes et restaurations ciblées. Il facilite aussi la remise des données en fin de contrat.

Comment le vérifier : une description de l’architecture multi-tenant dans le mémoire technique, avec le niveau d’isolation (base, schéma ou ligne).

4. Réversibilité réelle

La réversibilité est le critère que les acheteurs publics citent le plus souvent et vérifient le moins. Exigez qu’elle soit décrite : formats d’export (CSV, GeoJSON pour les données géographiques…), périmètre (interventions, comptes rendus, photos, pièces jointes, historique), délai et coût. Un export qui laisse de côté les photos ou les comptes rendus terrain n’est pas une réversibilité.

Comment le vérifier : une clause de réversibilité chiffrée, avec un jeu d’export d’exemple demandé pendant la phase d’analyse des offres.

5. Interopérabilité et formats ouverts

Un logiciel d’interventions dialogue avec un ERP de gestion locative, une GMAO, un SIG ou un outil de facturation. Les formats propriétaires et les interfaces fermées sont des mécanismes de dépendance : ils font grimper le coût d’une migration future. Privilégiez une API documentée et des formats standard (CSV, GeoJSON, Shapefile pour les échanges SIG).

Comment le vérifier : la documentation d’API fournie avec l’offre, et un scénario d’intégration testé pendant la démonstration.

6. Continuité de service, y compris sans réseau

La souveraineté, c’est aussi la résilience. Un technicien en sous-sol, en chaufferie ou sur un poste de relevage n’a pas toujours de réseau. Une application qui exige une connexion permanente rend l’exploitation dépendante d’un opérateur et de la couverture mobile. Exigez un fonctionnement hors ligne réel : saisie complète du compte rendu, photos, signature, puis synchronisation différée. Demandez aussi la fréquence des sauvegardes et la quantité maximale de données qu’une panne pourrait faire perdre (RPO).

Comment le vérifier : un test en mode avion pendant la démonstration, et la politique de sauvegarde écrite dans le contrat.

Ce que ces critères ne doivent pas devenir

Le droit de la commande publique impose des critères liés à l’objet du marché, proportionnés et non discriminatoires. Un acheteur ne peut pas rejeter une offre au seul motif que le fournisseur n’est pas français (Code Confiance). Les six critères ci-dessus portent sur des propriétés techniques et contractuelles mesurables. C’est ce qui les rend défendables, et c’est aussi la logique retenue par la Commission européenne pour son propre marché de cloud souverain, évalué sur une grille de critères plutôt que sur une étiquette.

En pratique, pondérez ces critères dans la valeur technique, demandez des preuves (annexes, documentation, tests) et faites-les figurer dans le contrat, pas uniquement dans le mémoire technique.

Comment G-ordon répond à ces critères

G-ordon est un logiciel de gestion des interventions terrain édité par Agiléo Solutions, à Toulouse, conçu et développé en France depuis 2018. Nos choix d’architecture recoupent directement les points ci-dessus :

  • production en France, sauvegarde de secours dans l’UE : la plateforme est hébergée chez Scaleway, dans sa région de Paris ; les sauvegardes, toutes les 6 heures, sont conservées à Paris, avec une copie de secours dans l’Union européenne ;
  • une base de données dédiée par client, et non une base partagée ; les documents et les photos sont eux aussi cloisonnés par client ;
  • des cartes OpenStreetMap servies par nos propres serveurs, avec G-ordon Planisphère, sans fournisseur de cartes tiers ;
  • des exports ouverts : Excel et CSV, GeoJSON pour les données géographiques, Shapefile d’ici fin 2026, et une API REST documentée pour dialoguer avec un ERP, une GMAO ou un SIG ;
  • la réversibilité, sur devis : vos données vous sont remises en CSV, et vos photos sur disque dur ;
  • une application terrain qui fonctionne hors ligne : le technicien remplit son compte rendu d’intervention sans réseau, et la synchronisation se fait au retour de la connexion ;
  • des comptes rendus d’intervention construits sur mesure, avec plus de 30 types de saisie, adaptés aux métiers du logement social, de l’eau et de l’assainissement ;
  • un fil d’échanges entre le bureau et le terrain, sans outil tiers à ajouter.

Le détail est sur notre page Sécurité et conformité, et les questions d’hébergement et de RGPD sont traitées dans la FAQ. Pour les acheteurs publics, G-ordon se commande aussi via une centrale d’achat. Pour un service d’eau ou d’assainissement, notre guide Logiciel d’exploitation réseau eau applique ces critères à l’exploitation du réseau.

En résumé

CritèrePreuve à demander
Hébergement et sauvegardesAnnexe d’hébergement nominative
Lois extraterritorialesListe des sous-traitants ultérieurs et leur pays
Isolation des donnéesDescription de l’architecture multi-tenant
RéversibilitéClause chiffrée et export d’exemple
InteropérabilitéDocumentation d’API, formats ouverts
Continuité hors ligneTest en mode avion, politique de sauvegarde au contrat

La souveraineté se joue dans le cahier des charges, puis dans le contrat.

Vous préparez un marché ou le renouvellement de votre outil d’interventions ? Nous vous montrons G-ordon sur vos cas réels : hébergement, exports, mode hors ligne, comptes rendus d’intervention, en visioconférence ou sur site.

Et si vous voyiez G-ordon sur vos propres cas ?

Une démonstration qui part de votre activité, pas d'une présentation générique.

Demander une démonstration

Articles associés

Guides 26 octobre 2026 8 min de lecture

Visites de contrôle des résidences : grille de propreté et méthode

Bailleur social : structurer les visites de contrôle des résidences, construire une grille de propreté et de sécurité, la noter et suivre les écarts, hors ligne.

En savoir plus

Guides 21 octobre 2026 6 min de lecture

Cahier des charges logiciel d'interventions : modèle

Modèle de cahier des charges pour un logiciel de gestion des interventions terrain : exigences fonctionnelles, hors ligne, hébergement, réversibilité.

En savoir plus

Guides 19 octobre 2026 6 min de lecture

Logiciel d'exploitation réseau eau : du terrain au CRI

Régies et délégataires eau et assainissement : structurer interventions, comptes rendus et cartographie du réseau avec un logiciel terrain hors ligne.

En savoir plus