Votre pair programmeur IA n’est pas le bienvenu en amont : une politique de contribution OSS pour 2026

L’open source a donné de l’avance à votre startup. Mais en 2026, votre pair programmeur IA n’est pas le bienvenu partout. Le projet Godot a annoncé publiquement qu’il n’acceptera plus de code rédigé par IA, point final. D’autres s’orientent discrètement dans le même sens. Si vos ingénieurs envoient des patchs générés par IA en amont, attendez‑vous à des rejets, des frictions et, dans certains cas, à des bannissements au niveau de l’organisation. Ce n’est pas un risque réputationnel théorique ; c’est un problème de pipeline et de politique que vous pouvez corriger.

Pourquoi c’est crucial maintenant

Trois courants viennent de se percuter :

• Les mainteneurs tracent des lignes rouges. L’interdiction de Godot est explicite. De nombreux projets exigent désormais un DCO signé et s’attendent à ce que vous puissiez attester légalement de la paternité. « Copilot l’a écrit » ne suffit pas.
• Les éditeurs ajoutent des signaux de provenance. Des développeurs rapportent que des agents d’IDE et des outils SaaS laissent des traces identifiables dans les requêtes ou le contenu. Même si la techno est imparfaite, partez du principe que les relecteurs peuvent et vont demander comment le code a été produit.
• Les workflows gagnent sur les modèles. La récente mise en avant d’Anthropic avec Claude Science privilégie le workflow à la puissance brute des modèles. À prendre comme un indice : c’est votre processus de contribution — pas votre catalogue de modèles — qui décide si l’amont accepte votre patch.

Le gain à bien faire les choses est concret. Des patchs acceptés en amont réduisent la taxe de maintenance de vos forks privés, diminuent la charge liée aux conflits de fusion et maintiennent votre posture de sécurité alignée sur les correctifs de la branche principale. À l’inverse, être étiqueté « déverseur de code IA » vous coûte du temps, du capital communautaire et de la vélocité.

Tracer la ligne : code rédigé par IA vs. assistance IA

Si vous dirigez l’ingénierie dans une startup ou une scale‑up, vous avez besoin d’une définition d’entreprise que vous pouvez défendre au regard du Developer Certificate of Origin (DCO) et des Contributor License Agreements (CLA) courants :

• Code rédigé par IA : code où la sortie d’un modèle constitue la logique substantielle du changement (ex. coller une fonction ou un module généré). À considérer comme interdit pour les projets qui bannissent les contributions IA.
• Workflow assisté par IA : usage des modèles pour des tâches ne relevant pas de l’écriture — revues de conception, génération d’idées de tests, édition de docs, synthèse d’API, plans de refactorisation — tandis qu’un humain écrit et assume le code. Souvent acceptable s’il est déclaré, et généralement sûr même là où l’écriture par IA est bannie.

Mettez cela par écrit. Formez vos équipes. Faites respecter via les outils. Vos pods nearshore doivent opérer selon le même référentiel que l’équipe du siège, avec la même plage de recouvrement de 6–8 heures/jour, afin d’éviter toute dérive de politique.

Le véritable paysage des risques

• Non‑conformité à la politique : les projets qui interdisent les patchs rédigés par IA rejetteront ou feront escalader. Quelques‑uns ont publiquement menacé de blocages au niveau de l’organisation en cas de récidive.
• Provenance de licence : des générateurs peuvent recracher du code sous licence. Vous pouvez ne pas le voir ; les mainteneurs, si. Si vous avez signé un DCO, c’est votre problème, pas celui du fournisseur.
• Confiance dans la supply chain : beaucoup d’écosystèmes évoluent vers une provenance plus forte (SLSA, attestations in‑toto, SBOMs). Si vous ne pouvez pas expliquer comment le patch a été produit, les équipes ne feront pas confiance à ce que vous avez livré.
• Exposition des données : si les prompts incluent du code propriétaire ou des détails de partenaires, les envoyer à des modèles tiers peut créer des voies de fuite. Traitez les prompts et les logs de chat comme sensibles.

Un cadre décisionnel pour contribuer sans drame

1) Classer les amonts selon leur politique IA

• Ban : pas de code rédigé par IA. Souvent pas de texte généré par IA non plus.
• Assist with disclosure : code rédigé par des humains OK ; divulguer toute assistance IA.
• Silent/unclear : pas de politique affichée. Par défaut, traiter comme Assist with disclosure.

Créez un registre lisible par machine dans votre organisation (par exemple, un petit fichier YAML dans un dépôt interne) qui mappe chaque amont ciblé à l’un de ces trois états, avec des liens vers la politique de chaque projet.

2) Définir des modes de fonctionnement IA par dépôt

• Dépôts Ban : désactiver les complétions de code inline et les générateurs. Autoriser la relecture, l’explication et l’édition de docs. Aucun collage de sortie de modèle dans les diffs.
• Dépôts Assist with disclosure : autoriser les générateurs pour les tests et la doc. Pour le code de production, exiger une réécriture humaine : la sortie du modèle peut inspirer, pas atterrir telle quelle. Divulguer l’assistance dans le template de PR.
• Dépôts Silent : traiter comme Assist with disclosure jusqu’à clarification par les mainteneurs.

Faites respecter cela dans votre IDE. Pour VS Code, utilisez les paramètres d’espace de travail pour désactiver des extensions spécifiques (Copilot, Codeium, etc.) par worktree. Conservez un espace de travail séparé pour chaque amont avec le bon mode intégré. C’est ennuyeux, et c’est justement l’objectif.

3) Ne copiez pas — transformez

Si un modèle vous a aidé à réfléchir, votre sortie doit être une transformation humaine : code écrit à la main, messages de commit avec votre voix, diff minimal. Gardez le patch petit. Un mainteneur acceptera bien plus volontiers une correction chirurgicale de 30 lignes qu’un dump IA de 600 lignes. Si un générateur a proposé 600 lignes, essayez d’atterrir les 60 qui comptent.

4) Traitez prompts et logs comme sensibles

• Par défaut, privilégier des modèles locaux ou à portée entreprise pour les opérations avec contexte dépôt. Gardez prompts et embeddings dans votre VPC.
• Masquez les identifiants propriétaires si vous devez utiliser des modèles SaaS. N’incluez jamais de secrets de partenaires ni de jetons internes dans les prompts.
• Conservez un log interne de l’assistance IA uniquement pour l’audit — pas pour l’amont. Rétention courte (30–90 jours) et accès contrôlé.

5) Joignez un pack de preuves à chaque PR

• Brève note de conception expliquant le bug/la cause racine, les contraintes et pourquoi cette approche.
• Diff minimal et lisible avec des tests ciblés. Les tests sont vos alliés ; les tests générés par IA sont généralement acceptables s’ils sont clairs et passent.
• Signature DCO et, si le projet le préfère, un CLA enregistré. Ne masquez pas la paternité derrière des bots.
• Divulgation optionnelle si la politique l’exige : « LLM utilisé pour des idées de cas de test et l’édition de docs ; le code est rédigé par un humain. »

6) Ajoutez un miroir de contribution avec garde‑fous

Utilisez Copybara (ou équivalent) pour maintenir un miroir propre pour les contributions en amont :

• Source : votre dépôt de travail interne (où les équipes peuvent utiliser l’IA librement pour l’idéation).
• Transform : Copybara applique des filtres : supprimer les gros fichiers générés, retirer les en‑têtes « Generated by … », normaliser les en‑têtes de licence, lancer des scans de secrets (gitleaks) et des contrôles de provenance de licence (scancode‑toolkit ou FOSSology).
• Destination : un dépôt public contrib où les patchs sont petits, attribués et conformes à la politique. À partir de là, vous ouvrez des PR en amont.

Cette séparation rend l’application de la politique mécanique, pas doctrinale. Elle vous offre aussi un point unique pour prouver une paternité propre si un mainteneur le demande.

Un plan 30‑60‑90 jours

Jours 1–30 : inventorier et éliminer les pièges évidents

• Inventoriez vos 50 amonts principaux par poids de dépendance et fréquence de changement. Relevez leur politique IA explicite (ou son absence).
• Publiez un one‑pager avec vos définitions « code rédigé par IA » vs « assistance IA », mappées aux catégories Ban/Assist/Silent.
• Configurez les IDE par espace de travail pour désactiver les générateurs sur les dépôts Ban. Utilisez des worktrees Git pour une séparation nette, dans l’esprit de la récente vague de workflows « parallel worktrees ».
• Ajoutez des hooks pre‑commit pour signaler les en‑têtes de fichiers générés, le boilerplate d’éditeur et les secrets. gitleaks + un passage regex léger pour les chaînes « Generated by … » courantes est un bon début.

Jours 31–60 : mettre un miroir de contribution sur le chemin

• Déployez Copybara pour transférer les patchs de votre espace de travail interne vers un dépôt public contrib. Verrouillez les transformations : nettoyage de licences, listes d’autorisation de fichiers, scans de secrets et plafonds de taille.
• Exécutez des scans de provenance en CI : scancode‑toolkit ou FOSSology pour les étiquettes de licence ; des outils de similarité (type MOSS/JPlag ou diff au niveau des tokens) pour détecter des collages issus de sources non compatibles.
• Standardisez les templates de PR par classe de politique. Incluez des cases pour la signature DCO et, si requis, une courte divulgation d’assistance IA. Restez concis.
• Formez vos pods nearshore (Brazil, 6–8 heures de recouvrement avec les fuseaux horaires des États‑Unis) au workflow afin qu’ils puissent livrer des patchs pendant les heures des mainteneurs. Exécutez des PR à blanc sur un dépôt à faible enjeu pour valider le miroir.

Jours 61–90 : institutionnaliser et mesurer

• Codifiez les exceptions : pour les dépôts qui autorisent le code rédigé par IA, documentez où et pourquoi vous l’utiliserez (ex. benchmarks, fuzzers, migrations).
• Créez des « OSS sheriffs » : deux ingénieurs seniors par tribu qui possèdent la relation avec l’amont et arbitrent les questions de politique.
• Suivez des métriques : taux d’acceptation des PR, taux de rework lié à la politique, temps jusqu’à la première réponse et taille moyenne des diffs. Revue mensuelle.
• Réévaluez la posture des éditeurs : préférez des modèles d’entreprise ou auto‑hébergés pour toute tâche riche en contexte. Traitez tout identifiant ajouté par un fournisseur dans le contenu ou les requêtes comme des métadonnées sensibles — faites‑les passer par une sortie réseau que vous contrôlez, ou n’envoyez pas.

Exemple concret : faire accepter un patch dans un dépôt Ban

Scénario : votre équipe dépend d’une base de données open source, FooDB. Elle affiche une interdiction des contributions rédigées par IA. Vous découvrez un bug qui affecte votre charge de travail.

1. Repro et conception : un ingénieur à São Paulo reproduit le problème, rédige une note de conception de 200 mots et esquisse une correction minimale. Il utilise un LLM en privé pour vérifier les cas limites et proposer des entrées de test. Aucun code généré n’est collé.
2. Worktree + réglages : il crée un worktree Git dédié pour FooDB avec les générateurs IA désactivés dans VS Code pour cet espace de travail.
3. Coder la correction : il écrit un patch de 28 lignes et 40 lignes de tests à la main. Le LLM reste en « mode relecture » pour critiquer la complexité et suggérer de petites corrections de doc.
4. Contrôles du miroir : pousser vers la branche contrib interne déclenche Copybara : normalisation de licence, gitleaks, scancode. Tout est au vert.
5. Ouvrir la PR : la PR inclut la note de conception, la signature DCO, et une case à cocher : « LLM utilisé pour des idées d’entrées de test et l’édition de docs ; le code est rédigé par un humain. »
6. Réponse : un mainteneur pose une question ; le patch est fusionné en 48 heures. Votre fork reste léger ; vos correctifs de sécurité arrivent de l’amont sans fusions manuelles.

Outillage pour vous éviter les ennuis

• Miroir de contribution : Google Copybara. Des alternatives existent, mais le modèle de transformations de Copybara est éprouvé pour les flux multi‑dépôts.
• Scanning : gitleaks pour les secrets ; scancode‑toolkit ou FOSSology pour la provenance de licence ; contrôles de similarité légers pour détecter des événements de collage à risque.
• Politique IDE : paramètres d’extensions à l’échelle de l’espace de travail ; fichiers « mode IA par dépôt » que vos scripts de bootstrap respectent.
• Hygiène d’auteur : signature DCO à chaque commit ; pas d’auteurs bots pour les changements substantiels. Si un projet requiert un CLA, automatisez la vérification dans votre template de PR.
• Modèles locaux/entreprise : pour les tâches riches en contexte (revue de conception, explication de code), utilisez des modèles auto‑hébergés ou à portée entreprise afin d’éviter les fuites de code sensible. Conservez les logs de prompts dans votre VPC avec une rétention de 30–90 jours.

Compromis à accepter

• Débit vs acceptation : désactiver les générateurs pour les dépôts Ban peut ralentir la rédaction des patchs de 10–20 %. Les taux d’acceptation et la bonne volonté des mainteneurs le compensent largement.
• Taxe de réécriture humaine : même si les modèles aident à réfléchir, les humains doivent écrire. C’est le coût d’une paternité conforme.
• Friction opérationnelle : miroirs et scans ajoutent des étapes. Automatisez‑les et ils disparaîtront en arrière‑plan.

Et les marqueurs « cachés » des fournisseurs et les détecteurs ?

Des développeurs ont signalé que certains outils d’IA ajoutent des identifiants ou des signaux aux requêtes ou au contenu généré. Traitez tout marqueur, en‑tête ou métadonnée spécifique à un fournisseur comme des données sensibles soumises à vos contrôles de confidentialité habituels. N’essayez pas de « battre » les détecteurs ; alignez‑vous plutôt sur la politique du projet. Si un projet bannit le code rédigé par IA, écrivez le code vous‑même. S’il autorise l’assistance avec divulgation, faites une brève divulgation et passez à la suite.

Angle nearshore : en faire un réflexe, pas une réunion

Brazil compte à lui seul plus de 750 000 développeurs et une forte participation à l’OSS. Vos pods nearshore peuvent devenir votre moteur d’amont — si vous leur donnez une politique claire et une voie tracée. Bloquez 6–8 heures/jour de recouvrement avec les mainteneurs US, donnez‑leur le miroir et les templates, et mesurez les taux d’acceptation. La différence entre « AI‑dump shop » et « contributeur apprécié » tient à la répétition ennuyeuse du bon workflow.

L’essentiel

En 2026, le moyen le plus rapide de faire accepter des patchs en amont est d’arrêter de débattre des modèles et de commencer à opérationnaliser la politique. Classez les dépôts, définissez des modes de fonctionnement, séparez les espaces avec Copybara, livrez des diffs concis avec des tests et divulguez l’assistance quand c’est requis. Votre marque — et votre vélocité de delivery — en dépendent.

Points clés

• Beaucoup de projets OSS rejettent désormais le code rédigé par IA ; considérez « assistance IA » comme relecture et documentation, pas comme logique collée.
• Classez vos amonts cibles en Ban, Assist with disclosure et Silent ; définissez des modes IDE par dépôt.
• Utilisez un miroir de contribution à la Copybara pour appliquer automatiquement des garde‑fous de licence, de taille et de secrets.
• Livrez des packs de preuves : brève note de conception, diff minimal, tests ciblés, signature DCO et divulgations requises.
• Préférez des modèles locaux ou d’entreprise pour les tâches riches en contexte ; traitez prompts et logs comme sensibles.
• Attendez‑vous à une « taxe » de 10–20 % sur le débit pour les dépôts Ban ; les taux d’acceptation et la réduction de la dérive des forks la compensent.
• Formez les pods nearshore au workflow ; mesurez l’acceptation des PR, le rework dû à la politique et le temps jusqu’à fusion.