1. Classer ce qui décrit le calcul et ce qui donne un accès
Commencez par les informations que votre programme consomme réellement. La taille de lot, le nom du modèle et le mode de traitement décrivent une expérience. Un jeton autorisant un téléchargement ou une clé ouvrant un stockage donne un accès. Le premier ensemble doit être explicable ; le second doit rester disponible seulement là où il est nécessaire.
La frontière ne se résume pas aux noms de variables. Un chemin peut révéler un client, une URL peut embarquer un identifiant, et un petit échantillon de données peut être confidentiel. Évaluez donc aussi le contenu des paramètres partageables. Publier la configuration et publier tous ses chemins absolus ne sont pas la même décision.
Le tableau propose un classement de travail. Il ne décrit pas les services installés sur une machine Kernodeck. Définissez pour votre projet qui peut lire chaque élément, à quel moment et dans quelle copie ; ne laissez pas cette décision au dernier export d’un notebook.
Faites défiler le tableau pour lire toutes les colonnes.| Élément | Rôle | Traitement proposé |
|---|---|---|
| Taille de lot, mode, seuil | Paramètres du calcul | Versionner et valider leurs valeurs. |
| Jeton, clé privée, mot de passe | Moyens d’accès | Fournir séparément et ne pas inclure dans les sorties. |
| Chemin, URL, identifiant de corpus | Contexte potentiellement sensible | Vérifier avant de partager ; préférer un identifiant logique. |
| Résultats et journaux | Preuves d’exécution | Choisir les champs conservés et contrôler le dossier transmis. |
2. Choisir une seule règle de priorité
Un paramètre présent dans le code, un fichier et une option de lancement devient ambigu si personne ne sait lequel gagne. Fixez une règle simple, par exemple : valeurs par défaut documentées, puis fichier de configuration, puis options publiques de la commande. C’est un contrat de votre application, pas une priorité universelle fournie par Python.
Validez après cette résolution. Refusez une clé inconnue afin qu’une faute comme batch_szie ne soit pas silencieusement remplacée par une valeur par défaut. Distinguez un entier, une chaîne représentant un entier et un booléen. Ajoutez ensuite les contraintes utiles : valeur positive, mode autorisé, combinaison de paramètres cohérente.
Enregistrez enfin une configuration effective limitée aux champs autorisés. Elle explique ce que le programme a utilisé, même lorsqu’une option a remplacé le fichier. N’obtenez pas ce document en sérialisant tout l’objet de configuration avant d’en retirer quelques mots de passe connus : choisissez d’abord ce qui peut y figurer.
3. Travailler un exemple sans connecter de service
L’exemple suivant est pédagogique et non exécuté. Il décrit une opération fictive de production de vecteurs avec un lot de huit éléments. Le mot embedding est ici un choix d’interface ; aucun modèle n’est chargé et aucune dépendance GPU n’est supposée installée. Aucun secret n’est nécessaire pour lire ou valider ce fichier.
Le module standard tomllib, disponible à partir de Python 3.11, lit le format TOML. Il transforme les valeurs du document en objets Python ; il ne décide pas qu’un lot de zéro est interdit dans votre application. Le contrôle de domaine reste explicite après la lecture.
Cet extrait accepte exactement deux clés et deux modes. Pour l’utiliser dans un projet, raccordez ensuite les arguments, la gestion des erreurs et les chemins de sortie. Les rejets attendus sont faciles à raisonner : batch_size à zéro, batch_size sous forme de chaîne ou ajout d’une clé token. Ce sont des cas à vérifier chez vous, pas des résultats mesurés ici.
batch_size = 8
mode = "embedding"import tomllib
with open("config.toml", "rb") as source:
config = tomllib.load(source)
if set(config) != {"batch_size", "mode"}:
raise ValueError("CONFIG_KEYS")
if type(config["batch_size"]) is not int or config["batch_size"] <= 0:
raise ValueError("CONFIG_BATCH_SIZE")
if config["mode"] not in ("embedding", "classification"):
raise ValueError("CONFIG_MODE")
public_config = {
"batch_size": config["batch_size"],
"mode": config["mode"],
}4. Fournir le secret seulement à l’étape qui en a besoin
Une étape travaillant sur un fichier déjà présent ne doit pas exiger un jeton de téléchargement. Demandez le secret à la frontière où l’accès devient nécessaire. Si cette étape est activée mais que son accès manque, arrêtez-la avec un message indiquant le canal attendu, sans afficher la valeur reçue ni recopier toute la requête.
Le canal dépend de l’environnement disponible : gestionnaire de secrets, fichier d’identifiants à accès restreint ou mécanisme d’injection prévu par votre organisation. Une variable d’environnement peut servir d’interface, mais elle reste une donnée accessible au processus et susceptible d’apparaître dans des diagnostics. Ne confondez pas commodité d’injection et protection complète.
Limitez l’accès au périmètre utile et prévoyez son remplacement. Une demande de préparation logicielle ne garantit pas la présence d’un gestionnaire de secrets. Vérifiez le mécanisme effectivement disponible avant de construire votre lancement autour de lui, puis évitez de transmettre le secret à des sous-processus qui n’en ont pas besoin.
5. Concevoir un journal utile sans copier l’entrée
Définissez quelques événements : configuration acceptée, fichier contrôlé, partition terminée, sortie validée. Associez-leur un identifiant d’exécution, une étape et un compteur. Une erreur CONFIG_BATCH_SIZE suffit pour retrouver la règle concernée ; elle n’a pas besoin de contenir le fichier complet.
L’OWASP recommande d’exclure notamment mots de passe, jetons d’accès et clés des journaux. Appliquez cette règle aussi aux exceptions, objets affichés pour déboguer et sorties de cellules. Un masquage appliqué au dernier écran ne retire pas ce qui a déjà été écrit dans un fichier ou une capture.
Pour partager un incident, préparez une petite sélection : versions utiles, paramètres autorisés, erreur et exemple synthétique reproduisant le problème. Évitez l’archive automatique du dossier entier. Relisez également les URL, en-têtes, chemins et lignes voisines de l’erreur ; un message apparemment anodin peut être entouré de données sensibles.
6. Vérifier la séparation avant de partager
Préparez trois essais : configuration valide sans étape distante, configuration invalide et étape exigeant un accès absent. Le premier doit pouvoir aller jusqu’à sa frontière fonctionnelle sans secret inutile ; les deux autres doivent donner des erreurs distinctes. Vérifiez aussi qu’une modification publique de la taille de lot apparaît dans la configuration effective.
Pour contrôler votre procédure de partage, utilisez une chaîne sentinelle manifestement fictive et sans pouvoir d’accès. Faites-la passer dans le même emplacement qu’un secret lors d’un exercice isolé, puis recherchez-la dans les journaux, exports et fichiers sélectionnés. Son absence est un contrôle limité de ce parcours, pas une preuve que toutes les fuites sont impossibles.
Ajoutez les fichiers privés appropriés à vos exclusions Git, mais vérifiez aussi les fichiers déjà suivis. La documentation de Git précise que gitignore concerne les fichiers non suivis ; ajouter un motif ne retire pas un secret déjà enregistré. Examinez ce que vous allez transmettre, pas seulement les règles censées l’exclure.
7. Réagir à une diffusion et conserver une trace exploitable
Si un accès a été exposé, cessez de le réutiliser et faites-le révoquer ou remplacer auprès du système qui l’a délivré. Supprimer une ligne du fichier courant ne rend pas les copies précédentes inoffensives. Identifiez les emplacements concernés pour retirer ce qui peut l’être et comprendre le périmètre de la diffusion.
Votre dossier reproductible peut ensuite conserver le nom du canal utilisé et les paramètres autorisés, sans conserver le secret lui-même. Un futur lancement demandera un accès valide au bon moment. Vous obtenez ainsi une procédure transmissible sans transformer l’archive de l’expérience en trousseau d’accès.
Cette méthode porte sur votre application et ses livrables. Elle ne garantit ni l’isolation de tout l’environnement ni l’absence de traces techniques ailleurs. Pour passer à l’exécution, associez-la à un environnement documenté, à des données contrôlées et à un suivi qui distingue progression et résultat validé.