IA & InnerSource
Alliance naturelle ou Menace silencieuse ?

• Moins de duplication, moins de maintenance
• Un savoir partagé, des efforts mutualisés
• Des contributeurs qui montent en compétence sur des projets variés

• Un assistant qui lit un code inconnu et l'explique en 10 secondes
• Un assistant qui génère une fonctionnalité, ses tests et sa documentation, en quelques minutes
• Un agent qui ouvre une merge request tout seul
• Un chatbot qui répond à n'importe quelle question
  • même sur un patrimoine documentaire de plus de 10 ans, en quelques minutes

• 🔓 Ouverture 👉 l'IA sait chercher, résumer et relier ce qui existe déjà
• 🪟 Transparence 👉 l'IA peut retrouver le pourquoi d'un code, même sans documentation
• 🤝 Mentorat 👉 l'IA sait accompagner un nouveau venu dans un code inconnu, à toute heure
• 🎁 Contribution 👉 l'IA sait générer du code en respectant des inputs, des normes

Avec un assistant IA alimenté par le catalogue interne, on peut :

• savoir rapidement si un projet « fait déjà ça » ou pas loin, et qui le maintient
• voir quels autres projets l'utilisent déjà
• trouver aussi les agents, prompts et skills des autres équipes : un agent est un composant InnerSource comme un autre
• réutiliser le skill d'une autre équipe qui vérifie qu'une merge request n'écrit pas de données personnelles dans les logs, plutôt que d'en réécrire un

Avec l'IA, on peut :

• Transformer les discussions de merge requests et d'issues en décisions lisibles par tous
• Générer le README à partir du code réel, pas d'une supposition, et le garder à jour
• Résumer automatiquement les changelogs, l'avancement et la roadmap pour les équipes invitées

Avec l'IA, un nouveau contributeur peut :

• se faire expliquer l'architecture, les conventions et l'historique du projet, au moment où il en a besoin
• poser les questions « bêtes » sans avoir peur de déranger
• se faire accompagner sur un premier patch, même imparfait

Mais tout ce qu'on vient de voir suppose une chose :

Donc, naturellement :

• Si on lui demande, il régénère un masqueur à base d'expressions régulières…
  • plutôt que de suggérer la bibliothèque qui connaît déjà la classification interne des données
• Chaque équipe, chaque dev obtient « sa » solution, plus vite que jamais
• Même chose pour les agents : chacun construit le sien, avec ses sources, ses règles et son niveau de sécurité, invisible pour les autres
• Le nombre d'implémentations parallèles augmente au lieu de diminuer - code et agents

• Les décisions ne se prennent plus dans l'issue, mais dans une conversation privée avec un assistant
• Le prompt et le contexte ne sont ni versionnés, ni relus, ni partagés
  • le code arrive, mais le « pourquoi » n'existe nulle part
• Les choix d'architecture ont l'air plausibles… mais personne ne peut dire qui les a faits, ni pourquoi

• « L'IA va savoir faire » remplace « je vais demander aux sachants »
  • alors qu'avec un contexte peu fourni, l'IA invente une réponse plausible plutôt que d'admettre qu'elle ne sait pas
• Les Trusted Committers ne transmettent plus : le savoir reste dans leur tête… et la relève ne se forme pas
• Le réflexe de collaboration s'atrophie : on produit vite, seul… en désapprenant à coopérer

• Un déluge de contributions générées, avec peu de contexte et peu de contrôle
  • imaginez 10 MR ouvertes en une heure là où il y en avait 2 dans le mois il y a un an
  • pas plus de mainteneurs pour les relire et les valider… et donc la tentation de déléguer la revue à l'IA
• Des agents qui ouvrent des MR en masse : l'équipe hôte ne choisit plus ce qu'elle reçoit, elle le subit
• Une contribution générée par IA sans revue humaine sérieuse, et la confiance dans les badges « contributeur » et « mainteneur » s'érode rapidement

• Brancher l'IA sur le patrimoine réel (index / RAG, serveur MCP sur le catalogue) pour qu'elle propose l'existant avant de générer
  • code source des projets, documentations technique et fonctionnelle, backlog et historique des tickets
• Documenter pour les humains et pour les agents : un AGENTS.md versionné, un README structuré, CODEOWNERS comme source de vérité du propriétaire
• Publier agents, prompts et skills au catalogue comme des composants, avec un mainteneur
  • quand l'agent de l'équipe A se trompe chez l'équipe B, on sait qui porte le bug
• Faire de « chercher avant de générer » une norme d'équipe, et suivre le taux de réutilisation (équipes utilisatrices, MR venues d'autres équipes)

• Garder les décisions dans l'issue ou la merge request, pas dans le chat avec l'assistant
• Versionner le prompt et le contexte à côté du code - c'est là que vit le « pourquoi »
• Étiqueter les contributions assistées par IA : une case dans le template de merge request, sans en faire un tribunal
• Décider et contrôler, en équipe, le niveau d'autonomie qu'on donne aux agents

• L'IA répond aux questions de premier niveau, le Trusted Committer garde du temps réservé pour accompagner les contributeurs
• Faire de la revue un moment de transmission, pas un tampon : expliquer les refus, pas seulement les signaler
• Brancher l'IA avec les sachants, pas les remplacer : elle cite la doc, l'issue et la personne à contacter
• Le contributeur doit pouvoir expliquer sa merge request sans son assistant

• L'IA propose, l'humain décide et signe la contribution
• L'IA fait la première passe, le Trusted Committer fait la revue, avec le même niveau d'exigence : qualité, sécurité, tests
• Contre le déluge : une issue discutée avant toute MR générée, un CONTRIBUTING.md qui exige le contexte (besoin, issue liée, tests)
• L'attribution reste claire : qui a contribué, pas juste quel modèle a généré le texte

🔓 Avant de générer
- Cherche d'abord dans le catalogue interne (serveur MCP « catalogue »)
- Un composant existe ? Propose une contribution, pas un nouveau projet

🪟 Décisions
- Les choix de conception vont dans l'issue, pas dans la conversation
- Versionne le prompt et le contexte dans prompts/, à côté du code

🤝 Accompagnement
- Trusted Committers : @equipe-data-privacy, permanence le mardi
- Tu ne sais pas ? Dis-le, et renvoie vers eux plutôt que d'inventer

🎁 Contribution
- Pas de merge request sans issue discutée au préalable
- Étiquette la MR « assistée par IA » : son auteur doit pouvoir l'expliquer

Nos deux scénarios, ce sont les deux trajectoires possibles :

• Catalogue découvrable + IA bien alimentée et contrôlée = contributions partagées, sous contrôle, et moins de duplication
• Silos + IA sauvage = duplication sans contrôle

1. Inscrire un repo pilote au catalogue : code, doc, CODEOWNERS et agents
2. Ensuite seulement, y brancher les assistants via un serveur MCP, avec les droits de l'utilisateur
3. Écrire l'AGENTS.md du pilote : les 4 garde-fous, noir sur blanc
4. Versionner prompts et contexte, et fixer l'autonomie des agents
5. Exiger une issue avant toute MR générée, une étiquette IA et une revue humaine en réservant du temps aux Trusted Committers pour accompagner les contributeurs
6. Suivre le taux de réutilisation, pas seulement la vélocité