Sovereignty <br/> is existential.

Assurez-vous de disposer des poids et de l'architecture du modèle, ainsi que du tokenizer et des configurations nécessaires à son bon fonctionnement. Vérifiez aussi que vous avez les droits de modifier le modèle, d'effectuer un fine-tuning, de le distiller, de le déployer et de conserver ce que vous construisez. Vous pourrez ainsi continuer à le faire évoluer sans dépendre du fournisseur d'origine.

Conservez les checkpoints et les pipelines d'entraînement et de post-entraînement utilisés pour développer les modèles. Ils vous permettent de reprendre le développement et de reproduire les travaux précédents, plutôt que de considérer chaque version du modèle comme un artefact final impossible à recréer. Votre framework d'évaluation vous permet de vérifier que le modèle fonctionne toujours comme prévu. Les dépendances d'exécution déterminent si vous pouvez l'exploiter dans un autre environnement.

Testez cette indépendance en pratique. Vous devez pouvoir reprendre l'entraînement à partir de votre propre checkpoint, reproduire une exécution de post-entraînement, déplacer le modèle vers un autre environnement de calcul et l'exploiter sans les services du fournisseur d'origine. Si ce n'est pas possible, une dépendance subsiste. Vos droits de licence et d'exploitation doivent aussi rester valables après la fin de la relation commerciale.

À mesure que vous adaptez vos modèles, versionnez les données, le modèle de base, le code et la configuration associés à chaque adaptation. Enregistrez les graines aléatoires, les métriques et les sorties de chaque exécution pour reproduire ce que vous avez construit, retracer les modifications et comparer les résultats de manière fiable dans le temps.

Conservez les jeux de données d'évaluation et les grilles de critères utilisés pour mesurer les performances. Vos outils de notation et vos seuils rendent ces critères applicables de manière cohérente. Vous évaluez ainsi chaque modèle et chaque adaptation selon vos propres exigences, plutôt que selon un benchmark générique du fournisseur.

Lorsque votre organisation utilise les modèles, consignez le contexte de leur utilisation en production. Les versions des modèles et des prompts, les informations récupérées et les appels d'outils indiquent les éléments dont disposait le système et la manière dont il s'est comporté. Les corrections, les actions et les résultats montrent ce qui s'est passé après la réponse du modèle et donnent des indications sur ses performances dans un workflow réel. Ensemble, ces éléments peuvent alimenter vos futures évaluations et améliorations.

Faites passer ces retours par un processus de relecture encadré. Seuls les signaux approuvés doivent devenir des ressources d'évaluation ou d'entraînement, et le comportement en production ne doit pas changer sans contrôle. Définissez séparément si ces données peuvent servir à améliorer un modèle partagé.

Vos modèles évolueront, mais vous devez conserver l'intelligence accumulée. Vos prompts, votre mémoire, vos ressources de recherche d'information, vos adaptations, vos évaluations et vos retours vous permettent de tester un modèle de remplacement selon vos critères établis, sans repartir de zéro.

Définissez des identités distinctes et des autorisations à périmètre limité pour les personnes, les services et les agents. Vous évitez ainsi qu'un agent obtienne davantage de droits que la personne ou le service qu'il représente. Les contrôles d'identité de l'entreprise établissent qui ou quoi agit, tandis que les identifiants délégués limitent les actions autorisées pour cette identité. Les identifiants à courte durée de validité limitent la durée de cet accès.

Appliquez des règles au choix du modèle, à l'accès aux données et à la recherche d'information avant l'exécution. Étendez ces règles aux outils qu'un agent peut utiliser, aux actions qu'il peut entreprendre et aux cas nécessitant une approbation. Les comportements interdits sont ainsi bloqués dès le départ, plutôt que découverts après coup. Les actions à fort impact peuvent nécessiter une approbation explicite ou une simulation avant leur exécution.

Les logs et les traces consignent ce qui s'est passé. Reliez les appels aux modèles et les prompts aux informations récupérées, aux outils, aux règles, aux actions et aux résultats. Vous pourrez ainsi reconstituer une exécution, analyser les défaillances et montrer quels contrôles ont été appliqués.

Versionnez les prompts, les agents, les workflows, les outils, les règles et les associations de modèles qui déterminent le comportement du système. Vous pourrez alors tester les modifications, les approuver et les annuler en cas de problème, dans un cadre maîtrisé.

Enfin, conservez la configuration, les correspondances d'identité et l'état opérationnel nécessaires au fonctionnement du système. Vous pourrez ainsi rétablir les contrôles et le comportement dont dépend votre IA en production après une panne, une mise à jour de composant ou un changement de fournisseur.

Une IA souveraine n'exige pas que tout s'exécute sur site. Chaque système d'IA peut fonctionner dans le périmètre de sécurité, juridique et opérationnel dont il a besoin. Certaines charges de travail peuvent utiliser une infrastructure partagée. D'autres peuvent nécessiter une infrastructure dédiée, votre propre VPC, un cloud privé, une infrastructure sur site ou un environnement déconnecté.

Identifiez où s'exécute le plan de données — l'environnement dans lequel vos charges de travail d'entraînement et d'inférence s'exécutent. Déterminez ensuite où s'exécutent les plans de contrôle et de gestion, qui les exploite et s'ils dépendent de services externes de licence, d'identité, de télémétrie, de mise à jour ou d'assistance.

Pour les systèmes critiques, garantissez la capacité, le débit et les niveaux de service dont vous avez besoin. Définissez la gestion des quotas, de la limitation du débit et de la contention pour savoir quelle capacité sera disponible lors des pics de demande.

Les mêmes règles doivent s'appliquer lorsque le fonctionnement normal est interrompu. Appliquez vos règles de placement aux capacités mobilisées lors des pics et des dépassements, ainsi qu'aux solutions de repli, de basculement et de reprise après sinistre. Un incident ne doit pas déplacer votre IA, sans contrôle, vers une zone géographique, un opérateur ou un environnement non approuvés.

La portabilité doit vous permettre de déployer le système dans un second environnement approuvé sans le reconcevoir. Conditionnez le déploiement dans des conteneurs portables et documentez la configuration de l'infrastructure, le matériel, les pilotes et les dépendances d'exécution nécessaires.

Des experts externes peuvent vous aider à adapter les modèles, à construire des évaluations, à intégrer l'IA à vos systèmes et à résoudre des problèmes d'infrastructure complexes. Assurez-vous que le transfert de compétences fait partie de leur mission. Vos équipes doivent connaître l'architecture et les décisions qui la sous-tendent, ainsi que les méthodes utilisées pour entraîner, déployer, exploiter et améliorer le système.

Donnez à vos équipes accès aux outils, aux artefacts et aux procédures opérationnelles nécessaires pour mettre ces connaissances en pratique. Elles doivent pouvoir reproduire une adaptation et évaluer elles-mêmes un modèle de remplacement. Elles doivent aussi pouvoir diagnostiquer un problème en production, changer d'infrastructure et rétablir le système sans faire revenir les experts d'origine pour le faire à leur place.

Les progrès de l'IA qui comptent sont ceux qui répondent à vos besoins : la fiabilité de ses performances au regard de vos données, de vos workflows, de vos évaluations, de vos contraintes économiques et de vos exigences opérationnelles. L'expertise externe doit accélérer ces progrès tout en renforçant la capacité de votre organisation à les poursuivre de manière autonome.