Une IA au sein du périmètre souverain, pensée pour les marchés publics dès la conception.

La souveraineté nationale détermine où résident les données et où s'exécute l'inférence. La protection des données citoyennes encadre leur traitement et leur traçabilité. La transparence des appels d'offres exige que chaque décision d'achat puisse être reconstituée. Le contrôle interne et le délégué à la protection des données attendent un enregistrement vérifiable sur chaque décision assistée par un modèle.

deeplinq fait entrer l'IA dans cette enveloppe, sans la maintenir à l'écart. Trois familles de processus — les services aux citoyens, le travail de connaissance interservices, la surveillance des marchés et des fournisseurs — auxquelles s'ajoutent la couche de preuve et l'enveloppe de déploiement.

Les décisions du secteur public sont des enregistrements soumis aux régimes de protection des données citoyennes, des pistes d'achat consultables des années plus tard, des reconstitutions qu'un organe de tutelle peut réclamer sans préavis, des contenus à diffusion restreinte dont la gestion de la classification ne se négocie pas. La résidence des données est une condition d'éligibilité. La provenance du modèle est une obligation de vérifiabilité.

Une réponse adressée à un citoyen, sans trace permettant d'en reconstituer l'origine, n'est pas défendable face à une demande de droit d'accès. Un résumé de surveillance des marchés sans citations renvoyant au dossier d'appel d'offres ne franchit pas le contrôle de diligence.

deeplinq maintient toute la chaîne au sein de l'environnement de l'institution — orchestration, connecteurs, agents, routeur de modèles, archive des requêtes, index de recherche, trace de décision. Sur site, sur un cloud souverain aligné sur l'ISO 27001, SecNumCloud ou un équivalent RGS, ou isolé du réseau là où la classe de données l'impose.

Examen de l'éligibilité aux prestations. Traitement documentaire à grande échelle — déclarations, demandes, dossiers. Réponse aux droits d'accès. Tri de la correspondance citoyenne. Le tout exécuté sur des systèmes de gestion de dossiers et des archives numérisées de façon inégale, configurés différemment d'un service à l'autre, dans des délais de réponse imposés.

La plateforme interroge ce socle. Avant : l'agent instructeur ouvre trois systèmes et un dossier papier, le délai continue de courir. Après : des requêtes en langage naturel — « résume la situation de revenus déclarée pour le dossier X, avec citations renvoyant à la source », « reconstitue l'historique des échanges que couvrirait une demande de droit d'accès » — renvoient des réponses citées qu'un DPD peut tracer.

Chaque interaction archive la requête, le contexte de recherche, la version du modèle et la trace de décision — lorsqu'un citoyen demande le relevé de chaque point de contact assisté par l'IA sur son dossier, l'institution exporte un dossier structuré, pas un chantier de reconstitution.

Les processus de service aux citoyens restent au sein de l'institution. Précisions sur les limites sur /scope/.

Rédaction de textes. Préparation de notes pour le cabinet. Préparation de notes entre directions. Une décennie de circulaires, de notes internes, de rapports commandés, de correspondance interdirections — chaque service dans son propre système de gestion documentaire. Les réponses sont là, dedans.

La plateforme interroge l'archive propre à l'institution. Avant : l'analyste de politiques extrait circulaires, notes et rapports de quatre instances de GED, l'échéance d'une note de cabinet qui approche. Après : « retrouve la justification développée au fil des trois dernières revues interdirections sur le sujet X » renvoie une réponse citée, version du modèle et contexte de recherche fixés.

Les contenus à diffusion restreinte suivent la posture de classification de l'institution. Le contrôle d'accès s'aligne sur le schéma de classification ; les recherches hors périmètre remontent comme des exceptions contrôlées, et non comme des occultations silencieuses.

Chaque recherche reste entre les murs de l'institution. Précisions sur les limites sur /scope/.

Dossiers de préparation d'appels d'offres. Archives des offres de fournisseurs. Rapports de diligence. Surveillance de l'exécution des contrats. Rapports d'audit post-attribution. Demandes citoyennes au titre de la transparence des marchés. Reconstituer la piste d'achat sur un seul contrat, c'est ouvrir quatre systèmes et lire une décennie de dossiers.

La plateforme interroge l'archive propre à la fonction achats. Avant : l'acheteur court après les offres de fournisseurs, les rapports de diligence et les constats d'audit répartis dans quatre systèmes, sous la pression d'un organe de tutelle. Après : « recoupe les trois dernières offres de fournisseurs sur cette catégorie de produits avec les constats de diligence » renvoie une réponse citée.

La préparation aux audits opère en amont. Les agents font remonter les engagements pris dans les contrats attribués dont la preuve d'exécution est mince et les constats de diligence incomplets au regard des attentes actuelles de conformité des marchés — un indicateur opérationnel, pas un jugement d'audit.

La plateforme lit les données d'achat et de fournisseurs que votre institution détient déjà. Précisions sur les limites sur /scope/.

Une revue de tutelle ne repose pas sur des affirmations, mais sur des preuves. deeplinq traite la couche de preuve comme un élément de premier plan, en cadrant ce qu'un auditeur des marchés, une fonction de contrôle interne, un délégué à la protection des données ou une demande citoyenne de droit d'accès reçoivent à partir de toute décision assistée par un modèle.

Chaque requête, chaque recherche, chaque appel de modèle et chaque action d'agent sont archivés avec leur contexte complet — attribution à la source, version du modèle figée, paramètres, horodatage, résultat, statut de validation humaine, évaluation du contrôle d'accès au regard du schéma de classification de l'institution.

Le verrouillage de la version du modèle en est la colonne vertébrale. Le modèle qui a produit une note il y a six mois est le modèle qui en reconstitue le raisonnement aujourd'hui.

Lorsqu'un organe de tutelle réclame un dossier de preuve circonscrit à un appel d'offres, à une interaction citoyenne ou à une session de rédaction précise, l'institution exporte une archive structurée. Aucun chantier de reconstitution. Aucune recherche du côté du fournisseur.

deeplinq ne certifie ni la conformité des marchés ni la qualification de souveraineté — aucune plateforme ne le peut. La qualification tient à votre posture de cloud souverain, à votre processus d'achat, à votre délégué à la protection des données et à vos relations de tutelle. Ce que produit deeplinq, c'est la piste de preuve qu'attendent vos organes de tutelle, vos contrôles de marché et votre délégué à la protection des données, avec la posture d'intégrité que votre fonction de conformité tient à préserver.

La résidence dans le secteur public ne pose pas une seule question. Les données elles-mêmes en posent plusieurs.

Les données personnelles des citoyens portent des obligations de résidence façonnées par le régime national. Les contenus à diffusion restreinte portent des contraintes de gestion de classification. Les données d'achat portent des obligations de transparence des marchés. Les actifs informationnels interservices suivent la posture souveraine propre à l'institution.

Verrouiller une plateforme du secteur public sur un seul fournisseur de modèle, c'est une décision de souveraineté, que l'institution la formule ainsi ou non. La feuille de route du fournisseur devient celle de l'institution. La juridiction du fournisseur devient une variable de la posture de résidence. Les mises à jour silencieuses du modèle deviennent des glissements silencieux dans la façon dont une note ou une décision d'éligibilité se trouve étayée un an plus tard.

deeplinq garde le choix du modèle derrière une interface que l'institution maîtrise. Des API cloud là où la classe de données et le régime de résidence autorisent l'appel à sortir du périmètre. Des modèles en poids ouverts, en inférence locale, là où ils ne l'autorisent pas.

Les modèles sont retenus selon la tâche, la classe de données et l'attente de tutelle. Les versions sont figées pour qu'une réponse produite lors de l'évaluation d'un appel d'offres se reconstitue à l'identique lors d'un audit post-attribution. Les modèles se remplacent sans réécrire la plateforme.