GitHub et .gitignore : ne jamais exposer ses clés API avec l'IA générative

Une clé API laissée en clair dans un fichier poussé sur GitHub est repérée par des scanners automatiques en quelques minutes, pas en quelques jours. Avec une IA générative qui écrit du code à votre place, ce risque devient plus fréquent : le fichier .gitignore et la variable d'environnement sont les deux réflexes qui l'évitent.

Qu'est-ce que GitHub, concrètement ?

GitHub est un hébergeur de dépôts de code fondé sur Git, le système de gestion de versions le plus utilisé au monde. Chaque modification de code y est enregistrée, horodatée et conservée dans un historique consultable. Un dépôt peut être privé (accès restreint) ou public (visible et cloné par n'importe qui, y compris par des robots).

C'est cette dimension publique qui change la donne. Un dépôt public n'est pas seulement visible par des humains curieux : il est parcouru en continu par des outils automatisés qui recherchent des motifs précis dans le code, notamment des formats connus de clés API, de jetons ou de mots de passe.

Comment une clé API finit-elle écrite en clair dans du code généré par IA ?

Quand on demande à un assistant IA de configurer une connexion à un service (base de données, API de paiement, modèle IA tiers), le chemin le plus court consiste à écrire directement la valeur du secret dans le fichier de code, sous la forme api_key = "sk-abc123...". Ce n'est pas malveillant, c'est simplement le résultat le plus rapide à produire.

Le problème apparaît au premier git push : si le fichier est suivi par Git et que le dépôt est (ou devient) public, la clé part avec le code. Elle reste consultable dans l'historique des commits même si elle est supprimée juste après, tant qu'elle n'a pas été révoquée chez le fournisseur, comme le rappelle la documentation GitHub sur la suppression de données sensibles.

GitHub exploite lui-même ce risque à des fins de protection : son mécanisme de secret scanning détecte automatiquement des dizaines de formats connus de secrets et alerte, parfois en quelques minutes. Des acteurs malveillants font la même chose, en continu, sur tous les dépôts publics.

Que fait le fichier .gitignore, exactement ?

Un .gitignore est un fichier texte, placé à la racine d'un projet, qui liste les fichiers et dossiers que Git doit ignorer : il ne les enregistre jamais dans l'historique, même s'ils sont présents sur le disque. C'est le mécanisme de base pour empêcher un fichier sensible de partir par erreur lors d'un commit, comme l'explique la documentation officielle GitHub sur l'exclusion de fichiers.

En pratique, le fichier .env (qui contient les variables d'environnement, dont les secrets) doit systématiquement figurer dans le .gitignore. Une ligne suffit : .env. La plupart des générateurs de projet créent ce fichier par défaut, mais un projet démarré rapidement avec une IA générative peut en être dépourvu, surtout si le .gitignore n'a jamais été explicitement demandé.

Point de vigilance : le .gitignore ne protège que les fichiers pas encore suivis par Git. Si un .env a déjà été ajouté à un commit avant d'être ajouté au .gitignore, il reste dans l'historique. Il faut alors le retirer explicitement du suivi (git rm --cached), en plus de l'ignorer pour l'avenir.

Quelle est la bonne pratique pour ne jamais exposer un secret ?

Trois réflexes couvrent l'essentiel des situations rencontrées par une PME qui code avec l'aide d'une IA. Aucun n'est technique au point de nécessiter un profil développeur confirmé.

Ne jamais écrire de clé API en dur dans un fichier de code. La clé doit vivre dans une variable d'environnement (un fichier .env local, ou les secrets configurés sur la plateforme d'hébergement), et le code y fait seulement référence par son nom. Cette distinction entre bases techniques (bases de données, OAuth, clés API) est développée dans l'article mère sur les fondamentaux avant de coder avec l'IA.

Vérifier le .gitignore avant le tout premier commit d'un nouveau projet, pas après. C'est le moment où la plupart des oublis se produisent : le projet vient d'être créé, le .env existe déjà avec de vraies valeurs de test, et le premier git push part avant que quiconque n'ait pensé à l'exclusion.

Traiter la sécurité comme un sujet d'audit régulier, pas un geste ponctuel. Cette dimension plus large (revue périodique, bonnes pratiques d'équipe) est traitée dans sécurité et IA générative : bonnes pratiques et audits en PME.

En pratique, comment rester vigilant selon l'outil IA utilisé ?

Claude (Claude Code, Claude Cowork)

Quand Claude Code génère un fichier de configuration ou un exemple de connexion à une API, demandez explicitement une variable d'environnement plutôt qu'une valeur en dur, et faites-lui vérifier ou créer le .gitignore avant le premier commit. Une simple consigne dans la demande initiale ("utilise des variables d'environnement, jamais de secret en clair") suffit à orienter tout le code généré ensuite.

ChatGPT et Codex

Codex peut lui aussi créer et pousser du code dans un dépôt connecté. Même principe : vérifier, avant toute action Git, que le .env figure dans le .gitignore généré, et relire les fichiers de configuration produits pour s'assurer qu'aucune clé n'y apparaît en clair.

Antigravity (agent IDE Google)

Antigravity travaille dans l'environnement de développement, avec accès au terminal et à Git. La vigilance porte sur les mêmes points : exiger une gestion par variables d'environnement, et relire tout git add ou git push proposé avant de le valider, surtout sur un projet fraîchement initialisé.