Livre blanc : ancrer un logiciel métier en France

Choisir un logiciel métier pour une administration, une collectivité ou un organisme régulé n'est pas un acte d'achat ordinaire. Derrière la question fonctionnelle — « cet outil fait-il ce dont nous avons besoin ? » — se cachent des enjeux de gouvernance, de souveraineté et de responsabilité qui conditionnent la pérennité du choix. Où sont hébergées les données ? Qui y accède ? Que se passe-t-il si l'éditeur disparaît ? Ces questions, souvent repoussées au moment de l'appel d'offres, devraient structurer la réflexion dès l'origine.

Ce livre blanc propose une grille de questions pour évaluer — ou construire — un logiciel métier ancré en France. Il ne s'agit pas d'un plaidoyer pour le « tout souverain » à n'importe quel prix, mais d'un cadre pour poser les bonnes questions au bon moment, en tenant compte des contraintes réglementaires, techniques et organisationnelles.

La grille s'adresse aux décideurs du secteur public et des secteurs régulés (santé, énergie, droit, éducation) qui doivent arbitrer entre solutions existantes et développement sur mesure.

Pourquoi la question de l'ancrage se pose maintenant

Pendant deux décennies, la tendance dominante a été de choisir des solutions SaaS hébergées « quelque part dans le cloud », sans trop se soucier de la localisation des serveurs ni de la juridiction applicable. Les raisons étaient pragmatiques : les offres étaient matures, les prix compétitifs, et les alternatives locales rares ou moins abouties.

Plusieurs évolutions changent la donne :

• Le RGPD impose des obligations strictes sur le transfert de données personnelles hors de l'Union européenne. Les décisions d'adéquation et les clauses contractuelles types ne couvrent pas tous les cas.
• La doctrine « Cloud au centre » de l'État français encourage les administrations à privilégier des hébergements qualifiés (SecNumCloud) pour les données sensibles.
• Les exigences sectorielles se renforcent : hébergement de données de santé (HDS), archivage légal, traçabilité réglementaire dans l'énergie ou les transports.
• La dépendance technologique est devenue un risque identifié : un éditeur qui change ses conditions, un hébergeur qui modifie sa politique de prix, une juridiction étrangère qui impose un accès aux données.

L'ancrage en France n'est pas une fin en soi. C'est une réponse à un besoin de maîtrise : savoir où sont les données, qui peut y accéder, et sous quelle juridiction les litiges seront tranchés.

Grille de questions : gouvernance des données

La gouvernance des données est le socle de tout choix logiciel dans un contexte régulé. Voici les questions à poser systématiquement :

Localisation et juridiction

• Où sont physiquement hébergées les données (production, sauvegardes, réplicas) ?
• Quelle juridiction s'applique en cas de litige ou de réquisition judiciaire ?
• L'hébergeur est-il soumis à des lois extraterritoriales (Cloud Act, FISA) qui pourraient contraindre l'accès aux données ?
• L'hébergement dispose-t-il d'une qualification reconnue (SecNumCloud, HDS) adaptée à la sensibilité des données traitées ?

Propriété et portabilité

• L'organisme reste-t-il propriétaire de ses données en toute circonstance ?
• Les données sont-eogiciel métier n'est pas un outil bureautique. C'est l'endroit où vit la preuve, la trace, la décision. Le choix de cet endroit est un acte de gouvernance. »

  Par où commencer

  Si vous êtes en phase de réflexion — renouvellement de marché, audit interne, ou simplement prise de conscience que l'outil actuel ne répond plus aux exigences — voici une démarche possible :

  1. Cartographier les données sensibles : quels dossiers, quelles données, quel niveau de sensibilité, quelle réglementation applicable.
  2. Poser les questions de la grille à vos éditeurs actuels ou aux candidats : localisation, juridiction, portabilité, réversibilité, accès.
  3. Évaluer le niveau de dépendance actuel : que se passe-t-il si l'éditeur change ses conditions dans six mois ? Si l'hébergeur est racheté ?
  4. Définir les non-négociables : hébergement en France, qualification SecNumCloud, export dans un format ouvert — chaque organisme a ses lignes rouges.
  5. Associer le terrain : les agents qui utilisent l'outil au quotidien sont les meilleurs juges de ce qui fonctionne et de ce qui manque.

  Sargo accompagne cette réflexion pour les organismes qui souhaitent ancrer leur logiciel métier en France, en cohérence avec les exigences de souveraineté et de conformité. Contactez-nous pour un échange, ou demandez à être rappelé pour un premier cadrage.

  lles exportables dans un format ouvert et documenté, sans surcoût ?
• En cas de résiliation, quel est le délai de restitution des données ? Sous quelle forme ?
• Existe-t-il une clause de réversibilité contractuelle, avec un plan de migration documenté ?

Accès et traçabilité

• Qui accède aux données : agents de l'organisme, prestataires, sous-traitants de l'éditeur ?
• Les accès sont-ils tracés (journalisation) et auditables ?
• Les données sensibles sont-elles chiffrées au repos et en transit ? Qui détient les clés ?
• L'éditeur peut-il accéder aux données de production pour du support ou de la maintenance ? Sous quelles conditions ?

« La question n'est pas "est-ce que nos données sont en sécurité ?", mais "est-ce que nous savons exactement qui peut y accéder, et sous quelle autorité ?" »

Grille de questions : hébergement et infrastructure

Architecture technique

• L'application est-elle mono-tenant (instance dédiée) ou multi-tenant (instance partagée) ?
• Les environnements de production, de test et de développement sont-ils séparés ?
• Quelle est la politique de sauvegarde (fréquence, rétention, test de restauration) ?
• Le plan de reprise d'activité (PRA) est-il documenté, testé, et compatible avec les exigences métier ?

Disponibilité et performance

• Quel est le niveau de disponibilité garanti (SLA) ? Est-il contractuel ou indicatif ?
• Les maintenances sont-elles planifiées, communiquées, et réalisées hors heures ouvrées ?
• Comment l'infrastructure réagit-elle à une montée en charge (scalabilité) ?

Indépendance technique

• L'application repose-t-elle sur des briques open source ou sur des composants propriétaires verrouillés ?
• En cas de défaillance de l'éditeur, un tiers peut-il reprendre l'exploitation ?
• Le code source est-il accessible (open source, escrow, licence spécifique) ?

Grille de questions : responsabilités et conformité

Responsabilités contractuelles

• Le contrat distingue-t-il clairement les responsabilités de l'éditeur, de l'hébergeur et de l'organisme client ?
• Les sous-traitants sont-ils identifiés et encadrés par des clauses de confidentialité et de sécurité ?
• La chaîne de sous-traitance est-elle transparente et stable (pas de changement unilatéral) ?

Conformité réglementaire

• L'éditeur fournit-il une documentation RGPD (registre des traitements, AIPD si nécessaire, DPA) ?
• Pour les données de santé : l'hébergeur est-il certifié HDS ?
• Pour les marchés publics : l'outil respecte-t-il les obligations d'accessibilité (RGAA) ?
• Les mises à jour réglementaires (facturation électronique, archivage légal, normes sectorielles) sont-elles intégrées dans la feuille de route de l'éditeur ?

Continuité et pérennité

• Quel est le modèle économique de l'éditeur ? Est-il viable à moyen terme ?
• L'éditeur publie-t-il une feuille de route produit ? Les engagements sont-ils tenus ?
• En cas de rachat ou de cessation d'activité, quelles protections existent pour les clients ?

Construire ou acheter : les critères de décision

La question « construire ou acheter » se pose différemment selon le contexte. Voici les critogiciel métier n'est pas un outil bureautique. C'est l'endroit où vit la preuve, la trace, la décision. Le choix de cet endroit est un acte de gouvernance. »

Par où commencer

Si vous êtes en phase de réflexion — renouvellement de marché, audit interne, ou simplement prise de conscience que l'outil actuel ne répond plus aux exigences — voici une démarche possible :

1. Cartographier les données sensibles : quels dossiers, quelles données, quel niveau de sensibilité, quelle réglementation applicable.
2. Poser les questions de la grille à vos éditeurs actuels ou aux candidats : localisation, juridiction, portabilité, réversibilité, accès.
3. Évaluer le niveau de dépendance actuel : que se passe-t-il si l'éditeur change ses conditions dans six mois ? Si l'hébergeur est racheté ?
4. Définir les non-négociables : hébergement en France, qualification SecNumCloud, export dans un format ouvert — chaque organisme a ses lignes rouges.
5. Associer le terrain : les agents qui utilisent l'outil au quotidien sont les meilleurs juges de ce qui fonctionne et de ce qui manque.

Sargo accompagne cette réflexion pour les organismes qui souhaitent ancrer leur logiciel métier en France, en cohérence avec les exigences de souveraineté et de conformité. Contactez-nous pour un échange, ou demandez à être rappelé pour un premier cadrage.

ères qui orientent la décision :

Acheter un logiciel existant quand…

• Le métier est suffisamment standardisé pour qu'une solution du marché couvre 80 % des besoins.
• L'organisme ne dispose pas des compétences internes pour maintenir un développement sur mesure.
• Le budget privilégie un coût récurrent prévisible plutôt qu'un investissement initial lourd.
• La solution existante est conforme aux exigences réglementaires sans adaptation majeure.

Construire un outil sur mesure quand…

• Le métier est trop spécifique pour qu'une solution standard s'adapte sans dénaturer les processus.
• La maîtrise des données et de l'infrastructure est un impératif non négociable.
• L'organisme dispose (ou peut constituer) une équipe capable de maintenir l'outil dans la durée.
• Le besoin évolue rapidement et exige une capacité d'adaptation que les cycles de release d'un éditeur ne permettent pas.

La troisième voie : un socle configurable

Entre le progiciel fermé et le développement from scratch, il existe une approche intermédiaire : un socle logiciel ouvert, configurable, qui fournit les briques de base (gestion de dossiers, fil chronologique, droits d'accès, traçabilité) et s'adapte au métier par paramétrage plutôt que par code. Cette approche combine la rapidité de mise en œuvre d'un logiciel existant avec la flexibilité d'un outil sur mesure.

C'est la direction que prend Sargo : un socle pensé pour les métiers régulés, configurable par domaine, hébergé en France.

Les pièges à éviter

L'expérience des projets logiciels dans le secteur public et les secteurs régulés fait apparaître des pièges récurrents :

• Le cahier des charges exhaustif : vouloir tout spécifier à l'avance conduit à des projets lourds, lents, et souvent décalés par rapport au besoin réel au moment de la livraison.
• Le « souverain washing » : un hébergement en France ne suffit pas si l'éditeur est soumis à une juridiction extraterritoriale ou si les données transitent par des serveurs étrangers.
• La dépendance à l'intégrateur : un outil très paramétrable mais dont la configuration exige un intégrateur spécialisé crée une dépendance aussi forte qu'un outil propriétaire.
• L'oubli de la réversibilité : ne pas prévoir la sortie au moment de l'entrée, c'est s'enfermer.
• Le mépris du terrain : un outil choisi par la direction sans consultation des agents qui l'utiliseront au quotidien a de fortes chances d'être contourné.

Où vit le dossier métier : la question structurante

Au fond, la question de l'ancrage d'un logiciel métier se ramène souvent à une question plus simple : où vit le dossier ? Le dossier usager, le dossier patient, le dossier abonné, le dossier de marché — peu importe le nom. C'est dans ce dossier que convergent les informations, les pièces, les événements et les décisions.

Si ce dossier vit dans un outil dont vous ne maîtrisez ni l'hébergement, ni les conditions d'accès, ni la pérennité, alors vous avez confié le cœur de votre activité à un tiers sans garantie de continuité. Pour approfondir cette réflexion, voir notre article sur la localisation du dossier dans les métiers régulés.

« Un l