Accueil
Accueil
Envoyer à un ami
Version imprimable
Partager
Gardez le lien...
L’État veut désormais maîtriser un “socle sans dépendance”. Techniquement, cela implique des choix d’architecture très structurants. Selon vous, quels sont les risques d’un socle trop centralisé en termes d’évolutivité, de dette technique ou de verrouillage technologique ?
Un socle numérique est nécessaire. C’est même logique. L’État doit sécuriser certaines briques critiques. La messagerie, la visio, les échanges de documents… c’est de la continuité d’activité. Mais un socle trop centralisé peut vite devenir un problème. On recrée une dépendance. Simplement différente. Le premier risque, c’est la rigidité. Si tout repose sur les mêmes briques, chaque évolution devient plus lente. On ralentit tout l’écosystème.
Le deuxième risque, c’est la dette technique. Un socle trop large devient vite monolithique. Chaque modification touche tout le système. Et puis il y a le risque de verrouillage technologique. Si les choix d’architecture sont trop prescriptifs, les éditeurs doivent se plier à ces choix. L’innovation se réduit. La bonne approche est plutôt un socle minimal. Quelques briques critiques. Bien définies. Interchangeables. La souveraineté ne vient pas d’un système centralisé. Elle vient de la capacité à remplacer une brique sans que tout s’effondre.
Le deuxième risque, c’est la dette technique. Un socle trop large devient vite monolithique. Chaque modification touche tout le système. Et puis il y a le risque de verrouillage technologique. Si les choix d’architecture sont trop prescriptifs, les éditeurs doivent se plier à ces choix. L’innovation se réduit. La bonne approche est plutôt un socle minimal. Quelques briques critiques. Bien définies. Interchangeables. La souveraineté ne vient pas d’un système centralisé. Elle vient de la capacité à remplacer une brique sans que tout s’effondre.
Vous évoquez une interopérabilité forte entre Jamespot et le socle de l’État. Concrètement, quels standards, protocoles ou API doivent être mis en place pour garantir cette interopérabilité sans compromettre la sécurité ni la performance ?
L’interopérabilité est un mot très utilisé. Mais techniquement, c’est assez simple.
Il faut d’abord des API ouvertes et documentées. Sans ça, l’intégration devient vite théorique. Ensuite il faut des standards d’identité. OAuth2, OpenID Connect, SAML. Sans fédération d’identité, on multiplie les comptes, les accès et les risques. Les formats d’échange doivent aussi être standards. JSON, OpenAPI, webhooks. Rien d’exotique.
Mais le point clé, c’est la gouvernance des API. Versioning clair. Documentation publique. Visibilité sur les évolutions. Sinon les éditeurs ne peuvent pas construire durablement dessus. Si une plateforme comme Jamespot veut intégrer une solution de visio, par exemple, il faut des API exploitables et du multi-provider réel. Sinon l’interopérabilité reste théorique.
Il faut d’abord des API ouvertes et documentées. Sans ça, l’intégration devient vite théorique. Ensuite il faut des standards d’identité. OAuth2, OpenID Connect, SAML. Sans fédération d’identité, on multiplie les comptes, les accès et les risques. Les formats d’échange doivent aussi être standards. JSON, OpenAPI, webhooks. Rien d’exotique.
Mais le point clé, c’est la gouvernance des API. Versioning clair. Documentation publique. Visibilité sur les évolutions. Sinon les éditeurs ne peuvent pas construire durablement dessus. Si une plateforme comme Jamespot veut intégrer une solution de visio, par exemple, il faut des API exploitables et du multi-provider réel. Sinon l’interopérabilité reste théorique.
La doctrine met en avant la souveraineté dans les achats publics. Cela suppose des exigences techniques spécifiques : hébergement, chiffrement, auditabilité, maîtrise du code… Quels sont, selon vous, les critères techniques les plus critiques pour qu’un éditeur soit réellement considéré comme souverain ?
La souveraineté numérique est souvent réduite à une question d’hébergement. C’est beaucoup plus large que ça.
Le premier sujet est juridique. Un éditeur ne doit pas être soumis à des lois extraterritoriales qui peuvent imposer l’accès aux données.
Ensuite il y a l’infrastructure. Les données doivent être hébergées en Europe et opérées par des acteurs européens.
Il y a aussi le chiffrement. Les clés doivent être maîtrisées par l’opérateur ou par le client.
L’auditabilité est également essentielle. Il faut pouvoir auditer le code, les dépendances, les chaînes de déploiement.
Et enfin la réversibilité. Les données doivent pouvoir être exportées facilement, dans des formats ouverts.
La souveraineté est aussi une question de résilience. Une violation n’est pas seulement un vol de données. Cela peut être une indisponibilité, une altération ou un blocage du système.
Le premier sujet est juridique. Un éditeur ne doit pas être soumis à des lois extraterritoriales qui peuvent imposer l’accès aux données.
Ensuite il y a l’infrastructure. Les données doivent être hébergées en Europe et opérées par des acteurs européens.
Il y a aussi le chiffrement. Les clés doivent être maîtrisées par l’opérateur ou par le client.
L’auditabilité est également essentielle. Il faut pouvoir auditer le code, les dépendances, les chaînes de déploiement.
Et enfin la réversibilité. Les données doivent pouvoir être exportées facilement, dans des formats ouverts.
La souveraineté est aussi une question de résilience. Une violation n’est pas seulement un vol de données. Cela peut être une indisponibilité, une altération ou un blocage du système.
Vous insistez sur la complémentarité entre un État architecte et un écosystème innovant. Comment éviter que la définition du socle — ses choix technologiques, ses cycles de mise à jour, ses contraintes de conformité — ne devienne un frein à l’innovation des solutions métiers qui doivent s’y intégrer ?
Le rôle de l’État est délicat. Il doit définir un socle. Mais il ne doit pas étouffer l’écosystème.
Sinon on remplace une dépendance privée par une dépendance publique.
L’État doit rester architecte. Pas acteur dominant de toutes les solutions.
Le socle doit fournir quelques briques techniques. L’identité, la communication, la sécurité.
Autour de ces briques, l’innovation doit rester ouverte.
Pour que cela fonctionne, il faut des API réellement ouvertes. Les mêmes conditions d’accès pour tous les éditeurs. Et de la transparence sur les feuilles de route techniques.
Sinon l’écosystème ne peut pas s’organiser.
Sinon on remplace une dépendance privée par une dépendance publique.
L’État doit rester architecte. Pas acteur dominant de toutes les solutions.
Le socle doit fournir quelques briques techniques. L’identité, la communication, la sécurité.
Autour de ces briques, l’innovation doit rester ouverte.
Pour que cela fonctionne, il faut des API réellement ouvertes. Les mêmes conditions d’accès pour tous les éditeurs. Et de la transparence sur les feuilles de route techniques.
Sinon l’écosystème ne peut pas s’organiser.
Peut-être une remarque plus personnelle, un conseil de lecture, un rendez-vous…
Je pense qu’on entre dans une phase assez intéressante du numérique public.
Pendant longtemps, la souveraineté numérique était un débat un peu théorique. Aujourd’hui, elle devient un sujet d’architecture, d’achat public et de stratégie industrielle.
La commande publique peut jouer un rôle énorme. Les États-Unis l’ont fait. Israël l’a fait.
La France peut le faire aussi.
Mais cela suppose une chose simple. Un socle ouvert. Interopérable. Et un État qui travaille avec son écosystème plutôt que de chercher à tout faire lui-même.
Et un rendez vous... Le Salon Digital Workplace ou les meilleures solutions seront mise en avant. A commencer par Jamespot bien-sûr !
Pendant longtemps, la souveraineté numérique était un débat un peu théorique. Aujourd’hui, elle devient un sujet d’architecture, d’achat public et de stratégie industrielle.
La commande publique peut jouer un rôle énorme. Les États-Unis l’ont fait. Israël l’a fait.
La France peut le faire aussi.
Mais cela suppose une chose simple. Un socle ouvert. Interopérable. Et un État qui travaille avec son écosystème plutôt que de chercher à tout faire lui-même.
Et un rendez vous... Le Salon Digital Workplace ou les meilleures solutions seront mise en avant. A commencer par Jamespot bien-sûr !
Alain Garnier, merci d'avoir répondu à nos questions, et au beau salon !
Alain Garnier est entrepreneur et cofondateur de Jamespot, éditeur français de solutions collaboratives lancé en 2005. Innovateur précoce, il avait fondé Arisem à 26 ans avant de créer plusieurs entreprises dans le numérique. Aujourd’hui CEO de Jamespot, il défend un numérique souverain, ouvert et centré sur l’humain, tout en s’impliquant activement dans l’écosystème logiciel français.
Pour aller plus loin...
Jamespot est un éditeur français de solutions collaboratives en mode SaaS, fondé en 2005 et spécialisé dans les réseaux sociaux d’entreprise, les intranets et les Digital Workplaces. La plateforme, modulable et personnalisable, aide les organisations à fluidifier la communication, structurer l’information et renforcer le travail d’équipe en toute sécurité. Jamespot est un acteur majeur du collaboratif souverain en France.