La souveraineté est un enjeu existentiel.

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 que vous avez aussi le droit 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 figé que vous ne pouvez pas recréer. Votre framework d'évaluation vous permet de vérifier que le modèle conserve les performances attendues. 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, gérez les versions des données, du modèle de base, du code et de 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 ensembles de données d'évaluation et les grilles que vous utilisez pour mesurer les performances. Vos outils de notation et vos seuils vous permettent ensuite d'appliquer ces critères de façon 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.

À mesure que votre organisation utilise les modèles, consignez le contexte de leur utilisation en production. Les versions des modèles et des prompts, les recherches de données et les appels d'outils indiquent les éléments dont disposait le système et son comportement. Les corrections, les actions et les résultats montrent ce qui s'est passé après la réponse du modèle et renseignent sur ses performances dans un workflow réel. Ensemble, ces éléments peuvent alimenter vos futures évaluations et améliorations.

Soumettez ces retours à un processus de revue 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 à votre insu. Contrôlez séparément si ces données peuvent être utilisées pour améliorer un modèle partagé.

Vos modèles évoluent, mais vous devez conserver l'intelligence accumulée. Vos prompts, votre mémoire, vos ressources de recherche de données, 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 à portée limitée pour les personnes, les services et les agents. Vous pouvez ainsi empêcher un agent d'obtenir plus 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 à durée de vie courte limitent la durée de cet accès.

Appliquez des règles au choix du modèle, à l'accès aux données et à leur recherche avant l'exécution. Étendez ces règles aux outils qu'un agent peut utiliser, aux actions qu'il peut effectuer et aux cas qui nécessitent une approbation. Vous bloquez ainsi les comportements interdits dès le départ, plutôt que de les découvrir 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 recherches de données, aux outils, aux règles, aux actions et aux résultats. Vous pouvez ainsi reconstituer une exécution, analyser les défaillances et montrer quels contrôles se sont appliqués.

Gérez les versions des prompts, des agents, des workflows, des outils, des règles et des associations aux modèles qui déterminent le comportement du système. Vous disposez alors d'un processus maîtrisé pour tester les modifications, les approuver et revenir à une version antérieure en cas de problème.

Enfin, conservez la configuration, les correspondances d'identités et l'état opérationnel nécessaires au fonctionnement du système. Vous pouvez 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'impose pas de tout exécuter sur site. Chaque système d'IA peut fonctionner dans le périmètre de sécurité, de juridiction et d'exploitation qui lui est nécessaire. 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, c'est-à-dire l'environnement qui exécute vos charges de travail d'entraînement et d'inférence. 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 pour les licences, l'identité, la télémétrie, les mises à jour ou l'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 des ressources pour connaître la capacité disponible lors des pics de demande.

Les mêmes règles doivent s'appliquer en cas de défaillance du fonctionnement normal. Appliquez vos règles de placement aux capacités mobilisées lors des pics et des débordements, ainsi qu'aux mécanismes de repli, de basculement et de reprise après sinistre. Un incident ne doit pas déplacer votre IA à votre insu vers une zone géographique, un opérateur ou un environnement non approuvé.

La portabilité doit vous permettre de mettre le système en service 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, à concevoir 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 un modèle de remplacement de manière autonome. Elles doivent aussi pouvoir diagnostiquer un problème en production, changer d'infrastructure et rétablir le système sans avoir à faire revenir les experts d'origine.

Le progrès en IA qui compte est le vôtre : 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 ce progrès tout en renforçant la capacité de votre organisation à le poursuivre de manière autonome.