Comment configurer .codeiumignore et les règles d'exclusion de dépôts dans Codeium

Les équipes d'ingénierie logicielle qui adoptent des assistants de programmation basés sur l'intelligence artificielle font face à une exigence stricte de conformité : s'assurer que les clés d'API, les certificats privés, les algorithmes propriétaires et les jeux de données de test ne soient jamais indexés ni transmis au cloud, tout en préservant une complétion de code fluide sur le reste du projet. Codeium répond à ce besoin via une architecture de filtrage à plusieurs niveaux combinant les fichiers .codeiumignore à la racine des projets, des exclusions globales sur les postes de travail et des règles de gouvernance centralisées dans la console d'administration d'entreprise.

Le moteur d'indexation de Codeium et les enjeux de sécurité

Pour définir des exclusions pertinentes, il convient de comprendre comment Codeium analyse les référentiels de code :

1. Reconnaissance du contexte local (Local Context Awareness) : Au sein de l'environnement de développement (VS Code, JetBrains, Windsurf ou Devin Desktop), le service d'indexation local découpe le code selon des frontières sémantiques (classes, fonctions, interfaces) pour générer des plongements vectoriels (embeddings). Lorsqu'un développeur saisit du code ou pose une question, le moteur extrait les fragments pertinents pour enrichir le prompt soumis au modèle.
2. Indexation distante multi-dépôts (Remote Indexing) : Dans les versions destinées aux entreprises, Codeium indexe les dépôts de manière centralisée côté serveur afin d'offrir une compréhension transverse entre microservices et bibliothèques partagées.
3. Risques de fuite de données : Sans exclusion explicite, les fichiers d'environnement (.env), les clés privées (.pem), les briques logicielles brevetées et les jeux de données contenant des informations personnelles peuvent être indexés. S'ils sont sélectionnés lors d'une requête sémantique, ces extraits sont directement envoyés au modèle lors de l'inférence.

Les règles d'exclusion empêchent ces chemins sensibles d'entrer dans la chaîne d'indexation dès l'origine.

1. Configuration au niveau du projet : .codeiumignore

Le principal outil pour circonscrire l'indexation d'un projet consiste à déposer un fichier .codeiumignore à la racine de l'espace de travail.

Emplacement et compatibilité

• Emplacement du fichier : À la racine même du projet (<repo-root>/.codeiumignore).
• Syntaxe : Suit strictement les motifs glob du format standard .gitignore.
• Compatibilité des environnements : Codeium, Windsurf et Devin Desktop prennent en charge nativement .codeiumignore. Les fichiers homologues tels que .windsurfignore et .devinignore partagent la même syntaxe et sont pris en compte conjointement par les agents de bureau.
• Comportement par défaut : Codeium respecte par défaut le fichier .gitignore existant, les dossiers masqués commençant par un point . et le répertoire node_modules. Toutefois, lorsque des modules propriétaires ou des données de test doivent rester suivis par Git mais doivent être dissimulés à l'assistant IA, .codeiumignore constitue la solution adéquate.

Modèle de configuration .codeiumignore pour la production

Voici une trame éprouvée, adaptée aux exigences des équipes d'ingénierie :

# ==============================================================================
# Secrets, certificats et variables d'environnement
# ==============================================================================
# Fichiers d'environnement local
.env
.env.*
!.env.example

# Clés cryptographiques, certificats et identifiants
*.pem
*.key
*.pkcs12
*.pfx
*.cert
*.crt
id_rsa
id_ecdsa
id_ed25519
credentials.json
service-account*.json
secrets/
config/secrets.yml

# Jetons de fournisseurs cloud et fichiers d'accès
.aws/
.gcp/
.azure/
*token*
*.secret

# ==============================================================================
# Propriété intellectuelle et algorithmes propriétaires
# ==============================================================================
# Moteurs de calcul exclusifs et briques cryptographiques internes
src/core/proprietary_engine/
src/crypto/internal_ciphers/
internal/patented_algorithms/

# Remarque : Décommenter les interfaces publiques si l'autocomplétion des signatures est requise
# !src/core/proprietary_engine/public_interfaces.ts

# ==============================================================================
# Données réglementées, PII et jeux de test volumineux
# ==============================================================================
# Sauvegardes de bases de données et instantanés de test
tests/fixtures/prod_dumps/
tests/data/sanitized_pii/
*.sqlite
*.sqlite3
*.db
*.dump
*.parquet
*.csv.gz

# ==============================================================================
# Artefacts de compilation et dépendances tierces (économie de ressources)
# ==============================================================================
dist/
build/
out/
target/
vendor/
node_modules/
*.min.js
*.min.css
*.wasm

Règles de syntaxe importantes

• Barre oblique finale pour les répertoires : Ajoutez systématiquement un slash (secrets/) pour cibler uniquement les dossiers et éviter de bloquer par mégarde un fichier source portant le même nom.
• Caractère générique récursif : Utilisez **/ pour cibler des sous-dossiers quelle que soit leur profondeur dans l'arborescence (par exemple, **/internal_keys/*.json).
• Ancrage à la racine : Une barre oblique initiale / limite l'exclusion au premier niveau (par exemple, /config/local.json n'impactera pas packages/app/config/local.json).
• Règles d'exception (!) : Le point d'exclamation réintègre un élément exclu. Cependant, si le répertoire parent est entièrement ignoré (secrets/), un sous-fichier (!secrets/public.json) ne peut être réactivé sans autoriser la traversée du dossier parent. Par ailleurs, les exceptions dans .codeiumignore ne prévalent pas sur des règles strictes définies dans .gitignore.

2. Configuration au niveau du poste de travail : exclusion globale

Pour protéger les dépôts récemment clonés qui ne possèdent pas encore de fichier .codeiumignore versionné, les équipes d'infrastructure peuvent déployer une politique par défaut sur les machines des développeurs.

Emplacement du fichier global

Créez le fichier dans le répertoire utilisateur :

• macOS / Linux : ~/.codeium/.codeiumignore
• Windows : %USERPROFILE%\.codeium\.codeiumignore

Fonctionnement

• S'applique automatiquement à l'ensemble des espaces de travail ouverts sur le poste.
• Se cumule avec les fichiers .codeiumignore et .gitignore locaux : dès qu'un motif correspond dans l'un de ces fichiers, la ressource est écartée de l'index.
• Les équipes informatiques peuvent déployer ce fichier à l'échelle de l'entreprise via des gestionnaires de dotfiles, des scripts Ansible ou des profils MDM.

3. Gouvernance d'entreprise et exclusion de dépôts sur serveur

Les fichiers de configuration locaux pouvant être modifiés par les développeurs, ils ne sauraient suffire pour satisfaire à des exigences d'audit strictes. Dans les offres d'entreprise (Codeium Enterprise ou Cognition Devin Enterprise), la gouvernance s'exécute depuis la console d'administration.

Liste d'autorisation des dépôts (Connecteurs SCM)

Lors de la connexion aux plateformes de gestion de code (GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center ou Azure DevOps) :

1. Autorisation explicite : Les administrateurs sélectionnent expressément les dépôts autorisés à être indexés par l'IA. Tout dépôt non coché demeure totalement exclu du moteur distant.
2. Filtrage par branche : L'indexation peut être restreinte aux branches maîtresses (main, release/*), ce qui évite que des branches de travail temporaires contenant des identifiants non assainis soient lues.

Contrôle d'accès basé sur les rôles (RBAC) et synchronisation IdP

La récupération de contexte respecte fidèlement les habilitations de chaque ingénieur :

• Synchronisation d'annuaire (IdP) : L'intégration SAML 2.0 ou OIDC avec Okta ou Microsoft Entra ID synchronise les groupes de sécurité de l'entreprise.
• Cloisonnement du contexte : Si un développeur ne dispose pas des droits de lecture sur un dépôt dans la forge logicielle, le moteur d'indexation n'intégrera jamais d'éléments issus de ce dépôt dans ses suggestions de code.

Règles impératives de permissions client

Sur les postes supervisés, les administrateurs peuvent imposer des règles de sécurité non modifiables :

{
  "deny": [
    "Read(~/sensitive-data/**)",
    "Read(/etc/security/**)",
    "Write(.env*)"
  ],
  "ask": [
    "Exec(git push*)"
  ],
  "allow": [
    "Read(~/workspace/standard-repo/**)"
  ]
}

La règle deny verrouille tout accès aux chemins critiques au niveau de l'agent local.

Synthèse des niveaux de contrôle

Une stratégie de défense en profondeur associe plusieurs échelons d'intervention :

Procédure de vérification et diagnostic

Après avoir configuré les règles d'exclusion, il est conseillé de vérifier leur prise en compte :

1. Contrôle des quotas de fichiers et de la mémoire

• Le moteur d'indexation local applique une limite de fichiers (généralement 10 000 fichiers pour une machine dotée de 10 Go de RAM).
• Les fichiers exclus ne sont pas comptabilisés dans cette limite et ne consomment pas de mémoire vive (environ 300 Mo pour 5 000 fichiers indexés).
• Le panneau d'état de l'indexation de l'éditeur doit afficher une baisse du nombre de fichiers pris en charge.

2. Test d'isolation de l'autocomplétion et du chat

• Ouvrez un fichier situé dans un répertoire exclu.
• Tentez d'appeler une fonction spécifique à ce fichier depuis un autre module pour observer si la complétion automatique reste muette. Dans le chat, interrogez l'assistant sur l'implémentation interne de cette fonction : il doit indiquer qu'il ne dispose d'aucun contexte.

3. Points d'attention pour le dépannage

• Option d'accès aux fichiers Gitignore : Vérifiez dans les préférences de l'éditeur l'option Gitignore access. Si elle est activée, l'agent peut consulter des fichiers exclus uniquement par .gitignore. Pour les fichiers sensibles, inscrivez-les toujours dans .codeiumignore.
• Mention explicite @fichier : Exclure un fichier de l'index passif n'empêche pas une lecture directe si un utilisateur le cite nommément avec @nom_fichier dans le chat. Pour bloquer toute lecture, configurez une règle administrative deny.
• Réinitialisation du cache d'indexation : Si des fichiers ont été indexés avant la création des règles, relancez l'espace de travail ou déclenchez une réindexation complète dans les paramètres pour purger le cache vectoriel existant.

Bonnes pratiques pour une sécurité en profondeur

Les fichiers d'exclusion constituent une barrière indispensable, mais ils s'inscrivent dans une démarche de sécurité globale :

1. Bannir les secrets en clair dans les dépôts : Utilisez des gestionnaires spécialisés (HashiCorp Vault, AWS Secrets Manager, Doppler) et transmettez les valeurs au moment de l'exécution par variables d'environnement.
2. Contrôle pré-commit automatisé : Intégrez des scanners comme Gitleaks ou TruffleHog dans les hooks Git et les pipelines d'intégration continue afin de refuser les commits contenant des identifiants.
3. Suivre .codeiumignore sous contrôle de version : Validez systématiquement .codeiumignore dans Git pour harmoniser le socle de sécurité de l'ensemble des contributeurs.
4. Recourir aux contrats de non-rétention (ZDR) et aux déploiements hybrides : Pour les activités réglementées, privilégiez les souscriptions Enterprise garantissant une absence totale de conservation des requêtes (Zero Data Retention) ou des déploiements hybrides où les index vectoriels restent cantonnés au VPC privé de l'entreprise.

Références

• Index a Repository - Devin Docs
• Local Agent Controls - Devin Docs
• Devin CLI Team Settings - Devin Docs
• Devin Desktop admin controls reference - Devin Docs
• Security at Cognition - Devin Docs