> ## Content Index
> Fetch the complete content index at: https://www.sfeir.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# Inner source, késaco ?
- URL: https://www.sfeir.dev/inner-source-kesaco/
- Published: 2026-11-06T09:23:05.000Z
- Updated: 2026-11-06T09:23:05.000Z
- Description: Comment contribuer au code d'une autre équipe sans attendre son backlog ? L'inner source applique les méthodes de l'open source à l'intérieur de l'entreprise.
- Author: Romain Lespinasse
- Tags: Késaco, opensource, DevOps, git

Une équipe mobile aurait besoin d'un champ de plus dans la bibliothèque d'authentification maintenue par l'équipe plateforme. La demande passerait par le backlog de cette dernière, et son délai dépendrait des priorités de l'équipe propriétaire. L'inner source ouvre une autre voie : que l'équipe demandeuse propose elle-même le changement.

> L'inner source applique à l'intérieur d'une organisation les méthodes de développement de l'open source : code visible, contributions ouvertes et revue par les mainteneurs.

## Définition

L'**inner source** désigne l'adoption, au sein d'une entreprise, des pratiques de collaboration des projets open source. Le code reste privé, accessible aux seuls membres de l'organisation, mais toute équipe peut le lire, proposer une modification et la faire relire par l'équipe qui le maintient.

## Explication

Dans un projet open source, n'importe qui peut ouvrir une *pull request* (une demande de fusion d'une modification dans le dépôt) sur un dépôt public. Les mainteneurs la relisent, la discutent, puis l'acceptent ou la refusent. L'inner source reprend ce fonctionnement et le limite aux équipes de l'entreprise.

Le modèle repose sur quelques éléments :

- **la visibilité** : le code est lisible par défaut par toutes les équipes, pas seulement par celle qui le développe ;
- **la contribution ouverte** : une équipe qui a besoin d'un changement peut le proposer, sans passer par la planification de l'équipe propriétaire ;
- **les mainteneurs** (*trusted committers*) : des membres de l'équipe propriétaire, responsables de la direction du composant, qui relisent les contributions et accompagnent les contributeurs ;
- **la documentation d'accueil** : un `README` qui explique à quoi sert le projet, un `CONTRIBUTING.md` qui décrit comment contribuer, et des tickets signalant les sujets accessibles à un nouveau venu ;
- **la découvrabilité** : un catalogue ou un moteur de recherche permet de trouver les projets ouverts à contribution.

Ces éléments correspondent aux pratiques décrites par la communauté [InnerSource Commons](https://innersourcecommons.org/?ref=sfeir.dev), qui rassemble des retours d'expérience et des *patterns* (des solutions éprouvées à des problèmes récurrents).

L'équipe propriétaire conserve la décision sur la feuille de route et sur ce qui est fusionné (*merge*), tout en partageant le travail. Cette ouverture a un coût pour elle : du temps de relecture et de documentation, pris sur son propre planning. Elle suppose aussi, selon les retours de la communauté, l'appui de la hiérarchie.

L'approche semble surtout pertinente lorsque plusieurs équipes dépendent des mêmes composants : bibliothèques communes, plateformes internes, outils de build. Elle apporterait peu à une équipe seule ou à des composants sans dépendances croisées.

## En pratique

Quelques fichiers suffisent pour ouvrir un composant à la contribution. Un `CONTRIBUTING.md` minimal, à placer à la racine du dépôt, à côté du `README` :

```markdown
# Contribuer à notre-bibliotheque

## Avant de commencer
- Ouvrez un ticket pour décrire le besoin avant de coder.
- Les tickets portant le label `bon-premier-ticket` sont accessibles sans connaître le projet.

## Proposer un changement
1. Créez une branche depuis `main`.
2. Lancez les tests (ici `npm test`, selon le projet).
3. Ouvrez une pull request : l'équipe propriétaire la relit sous cinq jours ouvrés.

```

Le délai de relecture est un exemple : l'équipe fixe celui qu'elle peut tenir. Une contribution qui reste sans réponse risque de décourager les suivantes.

Côté outillage, une plateforme Git interne (GitHub Enterprise, GitLab) suffit en général, à condition que les droits d'accès permettent aux équipes de lire les dépôts des autres. Les tests automatisés dans la CI (intégration continue) permettent aux mainteneurs de vérifier les contributions venues d'autres équipes. Une démarche proche de la [Documentation as Code](https://www.sfeir.dev/documentation-as-code-definition/) s'y prête : le `README` et le `CONTRIBUTING.md` vivent dans le dépôt et s'améliorent par *pull request*, comme le reste.

## Pour aller plus loin

Une façon de situer son organisation : une équipe peut-elle lire le code d'une autre équipe et lui proposer un changement sans autorisation préalable ? Si ce n'est pas le cas, un premier pas consiste à ajouter un `README` et un `CONTRIBUTING.md` à un seul composant partagé. Les guides et patterns d'[InnerSource Commons](https://innersourcecommons.org/?ref=sfeir.dev) donnent ensuite des points de départ concrets.