Valeur réplicable : la souveraineté technique ne s'arrête pas à la France

La souveraineté réduite à un drapeau, c'est un débat perdu d'avance.

Depuis quelques années, "souveraineté technique" est devenu un mot-valise. Il sert à justifier des choix de fournisseurs dans les appels d'offres publics, à alimenter des débats sur le cloud "souverain", à vendre des solutions françaises avec un argument patriotique. Ce n'est pas sans valeur — mais c'est insuffisant comme angle, et parfois trompeur.

Le vrai problème de fond, ce n'est pas la nationalité du datacenter. C'est la capacité à comprendre ce qu'on a construit, à le maintenir soi-même, à le transmettre, à le répliquer si besoin sans dépendre d'un acteur qui peut changer ses tarifs ou décider de pivoter son modèle commercial. Une solution hébergée en France mais illisible, non-documentée, impossible à auditer ou à migrer, ce n'est pas de la souveraineté — c'est juste un lock-in géographique.

La souveraineté technique, si on lui donne un sens utile, c'est une méthode. Elle s'exprime dans les choix d'architecture : est-ce que je peux ouvrir le capot ? Est-ce que je peux changer un composant sans tout réécrire ? Est-ce que quelqu'un d'autre, dans deux ans, peut reprendre ce travail sans moi ? Est-ce que je peux expliquer à une équipe ce qui tourne dans leur infrastructure, et pourquoi ?

Le cadrage que j'utilise

La question n'est pas "où est hébergé ce service ?" mais "est-ce que cette solution peut être reprise, adaptée, et reproduite par quelqu'un d'autre ?" Si la réponse est oui — et que la documentation est là pour le prouver — alors on est dans la souveraineté technique au sens opérationnel. Sinon, peu importe le drapeau sur le datacenter.

Et dès qu'on pose le problème comme ça, quelque chose change : on réalise que cette méthode n'a aucune raison de s'arrêter à la France.

Un problème résolu n'est jamais uniquement le sien.

C'est une conviction que j'ai développée progressivement, à force de voir les mêmes problèmes revenir dans des contextes très différents. Un problème de circulation d'information dans une PME industrielle d'Orléans ressemble structurellement à un problème d'information dans une association au Sénégal. Les contextes changent. Le type de friction, lui, revient souvent.

Quand on résout un problème avec une méthode — pas juste une rustine, une vraie méthode : documentée, composée de briques compréhensibles, reproductible — on crée quelque chose qui dépasse la situation initiale. On crée de la valeur pour tous ceux qui ont le même problème. Et ces gens sont souvent bien plus nombreux qu'on ne l'imagine quand on est dans le feu de la résolution.

C'est ce que j'appelle la valeur réplicable. Ce n'est pas un concept abstrait. C'est une posture de travail concrète : chaque fois qu'on traite un problème, on se demande — est-ce que ce qu'on construit ici pourrait être réutilisé ailleurs ? Est-ce que la documentation est assez claire pour que quelqu'un d'autre s'en saisisse ? Est-ce que les composants sont suffisamment standards pour être commandés localement n'importe où ?

Si la réponse est oui, alors ce qu'on a construit n'a pas juste de la valeur pour le client immédiat. Il a de la valeur pour un réseau de gens qui ont des problèmes similaires, dans des contextes différents, dans des géographies différentes. C'est ce principe que SISKIA incarne le plus directement.

SISKIA : la démonstration concrète.

SISKIA est une association que je préside. Son objet : développer des dispositifs de surveillance environnementale — détection d'incendie, surveillance de zones sensibles, monitoring de paramètres climatiques — adaptés aux contextes où l'infrastructure est rare, les budgets serrés, et les besoins réels et urgents.

La décision d'architecture centrale de SISKIA n'est pas technique au sens habituel. C'est une décision de méthode : tout le dispositif repose sur des composants standards du commerce — COTS. Pas de composants propriétaires, pas de module spécifique qu'on ne peut commander que chez un seul distributeur. Des composants qu'on trouve chez Mouser, DigiKey, ou dans un magasin d'électronique local à Marrakech, Dakar ou Lima.

La BOM (liste des composants) est publique. Les schémas sont ouverts. La documentation d'assemblage est rédigée pour être suivie par quelqu'un qui n'a pas travaillé sur le projet — pas pour les contributeurs originaux. Le protocole de communication choisi est LoRaWAN, une technologie bien documentée avec une masse critique d'implémentations open source. Les passerelles peuvent être fabriquées localement.

Ce que "reproductible" veut dire concrètement

Une association marocaine, sénégalaise ou péruvienne peut prendre la documentation SISKIA, commander les composants localement pour environ 30 euros par nœud, assembler le dispositif en suivant la procédure, et le déployer. Sans avoir besoin de nous contacter. Sans abonnement. Sans pièces de rechange importées de France. C'est ça, le reproductible — pas une version localisée d'un produit conçu pour un autre contexte.

Ce choix a des conséquences sur tout : sur la façon dont on documente (exhaustivement, pas pour nous), sur la façon dont on choisit les composants (disponibles partout, pas seulement optimaux), sur la façon dont on structure les versions (backward compatible, documentées, avec un changelog utile). Construire pour la réplicabilité, ça change la façon de travailler dès le début — pas à la fin.

Ce n'est pas une générosité de notre part. C'est de la cohérence avec la conviction posée plus haut : un problème résolu avec une méthode ouverte a plus de valeur qu'un problème résolu avec une méthode fermée. Parce que la valeur se diffuse.

Le même principe s'applique à la PME industrielle française.

Je ne travaille pas que sur SISKIA. La majorité de mes missions concernent des PME industrielles françaises — entreprises de 20 à 200 personnes, souvent dans la mécanique, l'électronique, la sous-traitance de précision. Et ce que je vois dans ces structures, c'est exactement le même problème sous une autre forme.

Ces entreprises ont souvent une dépendance à un fournisseur de logiciel ou de matériel qu'elles ne contrôlent plus. Une machine-outil dont le fabricant a été racheté et n'assure plus le support. Un ERP dont l'éditeur a changé ses conditions et dont la migration coûte 10x le budget initial. Un prestataire informatique qui est le seul à comprendre ce qui tourne dans l'infrastructure — et qui le sait.

Le problème de souveraineté technique d'une PME industrielle orléanaise n'est pas structurellement différent du problème d'une association sahélienne qui depend d'un fournisseur de capteurs dont les pièces s'importent à 6 semaines de délai. Dans les deux cas, la question centrale est : est-ce que j'ai la capacité de maintenir, réparer, faire évoluer ce que j'ai mis en place sans que quelqu'un d'externe décide à ma place ?

La réponse à ce problème est identique dans les deux cas : architecture basée sur des standards ouverts, documentation interne réelle (pas pour l'audit, pour l'usage quotidien), formation des équipes en interne plutôt que délégation permanente à un prestataire, et choix de composants ou d'outils dont on peut changer sans tout réécrire.

La réparabilité n'est pas qu'une vertu écologique — c'est une vertu économique et stratégique. Une machine réparable en interne, c'est une machine dont on n'est pas otage. Un ERP dont on peut extraire les données dans un format standard, c'est un ERP dont on n'est pas prisonnier. Ces décisions se prennent à l'architecture, pas au moment de la panne.

Ce que ça suppose comme posture : l'humilité du consultant face à l'expertise du terrain.

Il y a quelque chose d'important à dire sur la façon dont on intervient quand on travaille avec une logique de valeur réplicable. Et je vais être direct, parce que c'est un sujet sur lequel j'ai vu beaucoup de gens (dont moi, à certains moments) rater.

Les gens au fin fond du désert mauritanien, dans un village rural au Bangladesh, dans une périphérie de Lagos — ils connaissent leurs problèmes infiniment mieux que n'importe quel consultant qui viendrait les étudier trois semaines depuis son bureau. Ce n'est pas une formule — c'est une réalité opérationnelle. Ils savent ce qui casse, ce qui manque, ce qui coûte trop cher, ce qui est impossible à commander localement, ce qui résiste aux conditions climatiques, ce qui peut être réparé avec les outils disponibles sur place.

Ce qui leur manque, ce n'est pas qu'on leur explique leur problème. C'est qu'on leur donne accès à des outils — documentés, accessibles, reproductibles — pour résoudre eux-mêmes ce qui leur pourrit la vie. La différence entre les deux postures est massive. La première est condescendante et inefficace. La seconde est utile et respectueuse.

Ce que ça change dans la méthode de travail

Quand je conçois un dispositif avec une vocation réplicable — que ce soit pour SISKIA ou pour une architecture d'entreprise — je ne pars pas de l'hypothèse que je sais mieux que les futurs utilisateurs ce dont ils ont besoin. Je pars des contraintes réelles qu'ils m'ont décrites. Et je documente ces contraintes explicitement dans la documentation du dispositif, pour que la prochaine personne qui s'en saisit comprenne les choix — pas seulement les résultats.

C'est vrai pour SISKIA avec des associations en Afrique sub-saharienne ou en Amérique du Sud. C'est vrai aussi pour une PME industrielle française dont les techniciens connaissent leur machine infiniment mieux que moi. Ma valeur ajoutée n'est pas dans la connaissance du métier — elle est dans l'architecture, la documentation, la méthode de transmission. Dès que je confonds les deux, je rate.

L'humilité du consultant n'est pas une posture morale. C'est une condition de l'efficacité.

L'horizon : un réseau de structures qui se réplique, pas des produits qui se vendent.

Ce que je vise à terme n'est pas de construire une gamme de produits que ComiPi ou SISKIA vend. C'est de construire des méthodes et des architectures que d'autres peuvent s'approprier, adapter, et répliquer dans leurs contextes.

La différence est importante. Un produit qu'on vend crée une dépendance au vendeur. Une méthode qu'on diffuse crée de l'autonomie. Cette autonomie est exactement ce qu'une PME industrielle française cherche quand elle refuse de se faire enfermer dans un ERP propriétaire — et c'est exactement ce qu'une association sahélienne cherche quand elle veut déployer des capteurs sans dépendre d'une chaîne d'approvisionnement européenne.

Ce modèle suppose une chose que le modèle commercial classique ne suppose pas : accepter que la valeur créée dépasse largement ce qu'on en retire directement. Un dispositif SISKIA déployé au Mali sans qu'on soit impliqués dans le déploiement, c'est une réussite — pas un manque à gagner. Une PME française qui reprend notre architecture en interne et ne nous appelle plus, c'est une réussite — pas un client perdu.

Je ne suis pas naïf sur la dimension économique — ComiPi est une entreprise, SISKIA doit trouver ses financements. Mais la logique de valeur réplicable n'est pas incompatible avec un modèle économique. Elle change juste la nature de ce qui est valorisé : pas l'accès exclusif à une solution, mais la capacité à concevoir des solutions réplicables, à former des équipes à les déployer, à documenter ce qui a été appris.

Un fix résolu en France avec une méthode ouverte peut servir une association au Mali. Un fix résolu au Sahel face à des contraintes extrêmes — alimentation solaire, chaleur, connectivité intermittente, budget quasi-nul — peut éclairer des choix d'architecture pour une mission industrielle française qui n'avait pas pensé à ces contraintes sous cet angle. Les deux directions existent. Les deux ont de la valeur.

C'est ça, diffuser la capacité de création de valeur et de richesse à tous. Pas comme slogan — les slogans de ce type, on en voit partout. Comme méthode : des composants standards, une documentation publique, une architecture ouverte, une posture d'humilité face à l'expertise terrain, et la conviction que la valeur créée sera toujours plus grande que ce qu'on en retire seul.

Parlons-en.

PME industrielle qui cherche à reprendre le contrôle de son architecture, association qui veut déployer des dispositifs avec une logique COTS — si ce sujet résonne, je suis disponible pour un premier échange.

La suite

Le blog ComiPi

Arbitrages techniques, méthode terrain, cas clients. Des articles quand il y a quelque chose à dire — pas une newsletter quotidienne.