# Note d’intention

## Garantir un usage libre, juste et pérenne des outils logiciels qui contribuent au bien commun

Ce [livre blanc](https://fr.wikipedia.org/wiki/Livre_blanc) vise à augmenter la quantité et la viabilité des services numériques administrés en tant que communs, c’est-à-dire en tant que ressources mises en partage et exploitées de manière pérenne par une communauté.

Pour cela, il **clarifie le vocabulaire**, décrit les **contraintes minimales** sans lesquelles des ressources numériques ne pourront jamais accéder au statut de communs, et propose des **pistes concrètes** pour en faciliter l’émergence.

Ce document décrit les grandes catégories d’engagements mutuels et de comportements nécessaires pour garantir un usage libre, juste et pérenne des services numériques qui servent l’intérêt général, en particulier lorsqu’ils sont coproduits par des acteurs publics. Au-delà de ces catégories, il propose des bonnes pratiques qui permettent la constitution de véritables *communs* dans lesquels les usagers sont au cœur des décisions.

![](/files/-M4YkdHhMdYylHW_Psej)

## Public visé

Le public visé est en premier lieu les « innovateurs » \[Rogers, 1962] qui ont l'opportunité et l'intention d'organiser des communs, afin de les aider à confirmer leurs intuitions, à communiquer avec un vocabulaire clair et référençable, et à convaincre leurs pairs. J'entends par là que, si vous avez déjà une expérience d'administration des communs, vous-même ou votre organisation aura probablement des pratiques plus spécifiques et plus adaptées à votre contexte. Les recommandations formulées ici sont des bonnes pratiques qui permettent d'éviter les écueils habituels d'une stratégie d'ouverture basée sur de bonnes intentions mais qui échoue à la mise en œuvre ; il ne s'agit pas du seul moyen de faire émerger des communs.

Tout type de structure est concernée par les enjeux, de la grande entreprise à l'individu en passant par les associations et les administrations. Un sous-ensemble des recommandations visent spécifiquement les acteurs publics, qui sont plus contraints que d'autres et à la fois recèlent les plus grands gisements de services existants qui pourraient être mis en commun.


# Concepts

Avant de dérouler le raisonnement, j'éclaircis le vocabulaire et les concepts nécessaires à sa bonne compréhension.

Même si vous pensez avoir l'habitude des termes liés aux communs, à l'action publique et au numérique, je recommande la lecture rapide de ces chapitres car l'usage qui en est fait est souvent ambigu, alors que je les utilise ici avec un sens précis. Dans tous les cas, n'hésitez pas à y revenir au cours de la lecture !

Si l’importance, les enjeux et les questionnements des communs ne sont toujours pas clairs après la lecture de cette section, quelques [métaphores](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/6-annexes/1-metaphores.md) sont à votre disposition en annexe.


# Commun(s)

La complexité du vocabulaire des communs provient en premier lieu de l’usage du nombre et des déterminants pour désigner des concepts fondamentalement distincts.

On différenciera donc :

* *le* commun au singulier, qui est un principe politique de démocratie égalitaire dans l’accès à des ressources mises en partage, qui se décline en…
* *un* commun pour chaque ensemble de règles d’accès et d’usage déterminées de manière démocratique qui incarnent *le* commun, et qui génère…
* *des* communs, qui sont des instances de ressources mises en partage sur lesquelles est appliqué *un* commun déterminé par…
* *des* communautés, qui sont l’ensemble des acteurs rassemblés autour de chacun de ces communs.

Au-delà de leurs propriétés fonctionnelles, les communs sont donc en premier lieu des objets politiques \[Dardot, 2017], au sens où ce sont uniquement leurs règles d’usage et la réalité de leur application qui leur confèrent ce titre.


# Action publique

Les communs sont à distinguer des biens publics, tant du point de vue économique que du point de vue de la propriété. Les biens publics sont en effet le plus souvent à considérer comme le bien privé de l’administration publique \[Coriat, 2017]. De fait, sans règles établissant une gouvernance partagée avec ses usagers, des biens ou services ne peuvent être des communs. Pour autant, dans leur mission de défense de l’intérêt général, les acteurs publics sont fondés à avoir une politique des communs lorsque ceux-ci ont une utilité publique.

## Contribution <a href="#contribution" id="contribution"></a>

En premier lieu, les acteurs publics peuvent avoir un rôle d’investisseur qui soutient la création de ces communs. Cet investissement peut être financier, mais sera encore plus avantageusement d’expertise et de mise à disposition de ressources auparavant détenues en exclusivité. Par la mise en partage de ces ressources, l’acteur public devient un membre de la communauté plus qu’un simple mécène.

## Garantie <a href="#garantie" id="garantie"></a>

La puissance publique peut être utilisée pour garantir l’application du commun déterminé par la communauté, notamment en ce qui concerne les règles édictant l’accès et la non-réappropriation (*reenclosure*), et donc la préservation de leur statut.

Les acteurs publics sont généralement considérés comme les garants des modèles de propriété alternatifs à la propriété privée, et semblent donc a priori fondés à garantir cette non-réappropriation. En particulier, la prévention d’un basculement en gestion privée peut relever de leurs attributions lorsqu’ils ont contribué aux communs et qu’ils sont de fait comptable des ressources publiques investies.

Néanmoins, il est important de noter que les communs sont une option différant tant de la gestion publique que de la gestion privée et qu’un acteur public, pas plus qu’aucun autre, n’est fondé à les gouverner seul.

## Non-systématicité <a href="#non-systematicite" id="non-systematicite"></a>

De la même manière que tous les bâtiments publics n’ont pas vocation à être des bâtiments communs, tous les services publics numériques n’ont pas vocation à devenir des services numériques communs. Ce document n’a donc pas pour objectif de suggérer que les services publics numériques devraient tous se conformer à un commun.

Inversement, il n’est pas nécessaire de réunir toutes les conditions énoncées dans ce document pour commencer à construire des services numériques communs. Comme nous l’avons vu, le commun étant un principe politique, les logiciels peuvent devenir des communs même après avoir été totalement construits.


# Numérique

## Spécificités des objets numériques <a href="#specificites" id="specificites"></a>

Les objets numériques sont qualifiables de *communs* au même titre que peuvent l’être des ressources matérielles non-exclusives. La condition principale reste la même : le respect d’un commun. Néanmoins, deux particularités sont à noter en ce qui concerne les communs numériques.

D’une part, les pratiques qui prévalent dans le domaine du logiciel tendent vers des gouvernances facilitant la constitution de communs, là où les lieux physiques sont plus facilement par défaut des biens privés.

D’autre part, les coûts de la duplication et de la transmission de l’information sur support numérique étant extrêmement faibles, les communs numériques sont a priori non-rivaux \[Verdier & Murciano, 2015], c’est-à-dire que l’usage de leurs ressources par un acteur n’en prive pas d’autres acteurs.

## Communs numériques <a href="#communs-numeriques" id="communs-numeriques"></a>

Le terme de « commun numérique » se répand largement. On l’a beaucoup usité pour désigner des bases de données contributives telles qu’OpenStreetMap ou WikiData. Il est aujourd'hui souvent utilisé pour décrire le code source d’un logiciel libre.

Avec son appropriation plus large, il tend à désigner à la fois un code source et une instance exécutable gratuitement par le grand public de ce code source. Par exemple, « [Framatalk](https://framatalk.org/accueil/) » pour désigner une instance du logiciel libre [Jitsi Meet](https://meet.jit.si) administrée et hébergée par l’association [Framasoft](https://framasoft.org/).

Cette dernière acception est porteuse d’espoir pour la diffusion du concept dans la mesure où elle est beaucoup plus tangible que la désignation d’objets purement techniques, et recouvre une réalité d’usage plus à même de fédérer une communauté.

## Services numériques communs <a href="#services-numeriques-communs" id="services-numeriques-communs"></a>

Ce document se focalise sur les *services* numériques, c’est-à-dire des systèmes socio-techniques rendant un service à des humains et comprenant des interactions avec un logiciel. D’autres types de communs numériques existent en effet, à commencer par les bases de données (comme évoqué plus haut : OpenStreetMap, Wikidata…). Un sous-ensemble des éléments décrits dans ce document leur est applicable, mais nous ne traiterons pas explicitement ces cas.

On ne peut réduire les services numériques communs à leur code, pas plus qu’on ne peut réduire des services de distribution d’eau potable communs à un réseau de tuyauterie, et on ne peut donc pas non plus considérer que chaque exécution de ce code soit régi par un commun, même si l’une de ses instances l’est.

## Commun contributif <a href="#commun-contributif" id="commun-contributif"></a>

Si le code est effectivement une ressource non-rivale, certains des constituants (tels que décrits dans la section suivante) des services numériques communs peuvent, eux, être rivaux. Et en premier lieu, la capacité de contribution active de leur communauté, directement corrélée au temps investi par ses membres, est une ressource rivale.

C’est sur la base de ce constat que je distinguerai deux familles de services numériques communs : d'une part, ceux qui peuvent exister sans contribution active et continue de leurs usagers, et qui nécessitent une gouvernance qui garantit simplement la prévention de la réappropriation de ressources informationnelles stables ou autonomes (capteurs disséminés sur un territoire, capacités de calcul excédentaires…).

D’autre part, ceux dont la valeur informationnelle ne peut être maintenue que par l’investissement continu d’une multitude d’acteurs (encyclopédie, recommandations subjectives, agenda d’événements amateurs…), et qui nécessitent une gouvernance qui prévient la réappropriation non seulement des données consolidées, mais aussi de la capacité à contribuer de sa communauté.


# Constituants

Comme on l'a vu, les services numériques doivent disposer de règles de mise en partage pour que la gouvernance résultante puisse les amener à être considérés comme des communs numériques.

Plutôt que de donner un ensemble de règles prêtes à être appliquées de manière systématique, je décompose les services numériques en un ensemble de constituants et définis des contraintes qui encadrent le type de règles applicables sur chacun d'entre eux. Il s'agit ainsi d'une méta-méthodologie : il est impossible de donner des règles toutes prêtes pour chaque situation, mais il est possible de déterminer des contraintes que doivent remplir ces règles uniques pour que la gouvernance résultante puisse prétendre au statut de commun numérique.

Je décompose donc les services numériques communs selon les constituants suivants, ordonnés par niveau d'abstraction : code source, conditions d’usage, données produites par les usagers, statistiques d’usage, moyens de communication, marque, et stratégie d'évolution. Cette grille d’analyse rend saillants des aspects des services numériques qui sont souvent considérés comme périphériques. Pour autant, si l’un de ces constituants n’est pas mis en partage, cela ouvre des failles permettant la réappropriation de ressources informationnelles nécessaires à l’opération du service à moyen ou long terme.

> Par exemple, un service numérique dont le code source est sous licence libre mais dont la marque ne peut être utilisée que par une seule structure ne peut pas être considéré comme un service administré en commun.

Au-delà de contraintes de base à appliquer sur les règles de mise en partage de chacun de ces constituants pour garantir leur pérennité, je définis également des contraintes supplémentaires pour les services dont la valeur est fonction de la capacité de contribution active de leur communauté. En effet, dans ce cas-là, la capacité de contribution est directement corrélée au temps investi par ses membres, et est donc une ressource rivale.

Ces contraintes sont résumées dans la grille ci-dessous, et sont justifiées et détaillées dans les pages suivantes.

|                                                                                   Constituant                                                                                   |                                                         Contrainte sur la règle                                                        | Contrainte supplémentaire si valeur contributive |
| :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------: |
|          [Code source](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/1-code_source/README.md)          |                                                        Licence libre (ex : MIT)                                                        |         Clause de repartage (ex : AGPL3)         |
|          [Conditions d’usage](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/2-usage/README.md)         |                                CGU sans condition autre que la protection des droits des autres usagers.                               |          Garantie de disponibilité (SLA)         |
| [Données produites par les usagers](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/3-donnees/README.md) |                                                       Licence libre (ex : CC-BY)                                                       |        Clause de repartage (ex : CC-BY-SA)       |
|     [Statistiques d’usage](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/4-statistiques/README.md)     |                                                        Licence ouverte (ex : LO)                                                       |          Clause de repartage (ex : ODbL)         |
|   [Moyens de communication](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/5_communication/README.md)   | Représentativité de la communauté dans l’émission du message ou distribution de la possibilité d’envoyer des messages à la communauté. |                                                  |
|               [Marque](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/6-marque/README.md)               |                          Licence et charte d’usage des éléments constitutifs de l’identité (nom, URL, logo…).                          |                                                  |
|      [Stratégie d'évolution](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/7-strategie/README.md)      |        Transparence sur les ressources disponibles et définition des priorités fonctionnelles par les membres de la communauté.        |                                                  |

Attention, à ce stade, nous n'avons pas précisé les modalités d’organisation qui rendront effectives les règles déterminées sur la base de ces contraintes. Ainsi, pour que ces règles communes soient pleinement effectives et fassent partie d'une gouvernance complète, il faut également déterminer *qui* agit et dans quel cadre dans les cas d’infraction, par exemple en cas de non-respect des licences accordées sur les ressources mises en partage. C'est l'objet du [chapitre suivant](/3-roles).


# Code source

Les services numériques sont en premier lieu des logiciels. Même si on ne peut par définition pas les réduire à cette essence technique, leur première nature est l’exécution d’un code informatique. Ce code, dans une forme lisible et exécutable, est donc un constituant évident à mettre en partage.

## Licence libre

Les règles applicables à un code source sont formalisées par des licences, c’est-à-dire des contrats par lequel le titulaire des droits d'auteur définit les conditions dans lesquelles ce programme peut être utilisé, diffusé ou modifié. Certains types de licences, les licences libres, garantissent des droits au public : lecture, duplication, redistribution. Ces droits empêchent donc la réappropriation de l’existant.

**Une contrainte minimale est la mise à disposition du code source sous une licence libre.**

**Recommandation opérationnelle : utiliser une licence EUPL ou l’une des licences mentionnées à l’article** [**D323-2-1 du code des relations entre le public et l’administration (CRPA)**](https://is.gd/rYk7h7)**.**

## Clause de repartage <a href="#repartage" id="repartage"></a>

Néanmoins, les communs numériques ne peuvent être réduits à un logiciel. Comme on l’a vu, leur spécificité provient de l’existence d’une *communauté*. C’est bien cette communauté rassemblée autour du logiciel qu’il faut préserver pour éviter la réappropriation, active ou par désertion de la communauté à l’exception d’un acteur.

La réappropriation active ne peut être empêchée que par la mise en œuvre d’une clause de repartage \[Aigrin, 2002]. Une telle clause garantit que des améliorations apportées au logiciel sont mises à disposition de la communauté, en rendant obligatoire la publication des modifications du code source. En l’absence d’une telle clause, il suffit de reprendre le code source de logiciels constituant des communs numériques et d’y ajouter une fonctionnalité attirante pour les utilisateurs sans partager le code qui ajoute cette fonctionnalité \[Aigrin, 2002] pour déplacer la communauté vers cette nouvelle version \[Verdier & Murciano, 2015] qui n’est plus gouvernée par un commun, vidant de ce fait les communs originaux de leur substance. Une licence de repartage est donc la plus adaptée au cas des communs contributifs.

**Pour le services contributifs, la licence inclut la mise à disposition du code source avec une clause de repartage.**

**Recommandation opérationnelle : utiliser une licence Affero GNU Public License 3.**

## Sollicitation des intégrations <a href="#solliciter-integration" id="solliciter-integration"></a>

Au-delà de l’usage, la capacité des usagers à contribuer au service doit être préservée. L’usage de licences libres garantit le droit de modifier le code, mais la contribution signifie également l’évaluation systématique de ces modifications et leur intégration chaque fois que cela s’avère pertinent. Sans cette capacité à contribuer, les logiciels libres ne sont qu’une nouvelle forme de monologue.

**Une contrainte minimale est de fournir un moyen de solliciter l’intégration de modifications effectuées par un contributeur dans la base de code originelle.**

**Recommandation opérationnelle : exploiter les outils spécialisés dans le développement collaboratif, qui fournissent une plateforme consolidée permettant à la fois la mise à disposition du code et la contribution de code et de suggestions d’améliorations, comme** [**Framagit**](https://framagit.org/)**,** [**GitLab**](https://about.gitlab.com) **ou** [**GitHub**](https://github.com)**.**

## Engagements sur les intégrations <a href="#delai-traitement" id="delai-traitement"></a>

Au même titre que l’usage, la « contribuabilité » des communs ne saurait être mesurée par la seule capacité technique à solliciter l’intégration de modifications. Un contributeur dont les sollicitations ne sont jamais traitées sera rapidement frustré et cessera de contribuer, et la visibilité publique de cette absence de réponse en découragera d’autres.

**Il est utile de prendre un engagement sur le délai de traitement des sollicitations d’intégration de modifications ainsi qu’une charte de communication avec les contributeurs potentiels, afin de garantir une atmosphère ouverte et engageante.**

**Recommandation opérationnelle : mettre en place et publier un règlement intérieur décrivant les modalités de gestion des sollicitations d’intégration de modifications.**

## Documentation opérationnelle <a href="#ops" id="ops"></a>

Dans cet objectif également, les modalités techniques qui permettent l’opération du service, au sens de son administration système, devraient être également documentées et partagées au même titre que le code source : si une seule personne (physique ou morale) a connaissance de l’infrastructure nécessaire à l’opération du service, le risque de réappropriation est présent.

**Une contrainte minimale est la documentation des modalités d'opération technique du service.**

**Recommandation opérationnelle : documenter de manière exécutable par le biais d’un** [**système de gestion de configuration**](https://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle)**, qui permet de définir l’infrastructure comme du code.**


# Usage

Certains services peuvent être fournis par la simple exécution du code (par exemple, la compression d’images sur un ordinateur personnel). Dans ces cas-là, le régime d’usage dérive du régime d’accès au code source. Dans d’autres cas, la duplication du code source ne permet pas la duplication du service rendu, par exemple en cas d’interfaçage avec des ressources privées telles qu’API ou dans le cas d’un service appliquant une stratégie de plateforme (Colin & Verdier, 2013). Dans ce second cas, la prééminence de la valeur des effets de réseau par rapport à la valeur du code lui-même rendent extrêmement difficile la réplication du service.

## CGUs permissives

Cette potentielle impossibilité *de facto* à apporter une alternative aux modalités d’usage du service numérique quand bien même le code source serait duplicable *de jure* montre que le droit d’usage relève des constituants à part entière de la ressource partagée et non systématiquement d’une instance de cette ressource dont chaque variante pourrait imposer son propre droit d’usage.

**Une contrainte minimale est que les conditions générales d’utilisation doivent permettre l’usage sans conditions autres que celles strictement nécessaires à l’opération du service et à la prévention des actes visant à réduire la capacité d’autres usages.**

**Recommandation opérationnelle : transformer les contraintes juridiques en un espace d’information pour les usagers, en utilisant un langage clair et lisible qui catégorise les conditions d’usage selon leurs questionnements (**[**exemple**](https://mes-aides.gouv.fr/cgu)**).**

## Budget de contribution <a href="#budget-contribution" id="budget-contribution"></a>

Au-delà des garanties juridiques, des garanties techniques sont appropriées pour que la liberté d’usage puisse être effective. Dans le cas d’un commun minimal, une qualité de service insuffisante peut être remédiée par la création d’un service alternatif sur la base du code. Mais, dans le cas d’un commun contributif, il faut que l’instance à travers laquelle la communauté collabore soit fonctionnelle. Si le service est en maintenance permanente, même les CGU les plus ouvertes ne pourront en permettre l’usage.

**Pour les services contributifs, une contrainte porte sur un engagement sur un taux de disponibilité du service pour ses usagers (SLA). Pour ne pas freiner l’évolution du service, ce SLA doit évoluer dans le temps et être interprété comme un « budget de contribution ».**

**Recommandation opérationnelle : déterminer le SLA selon le nombre d’usagers et la capacité de traitement des agents humains à gérer des anomalies en s'assurant de la facilité et de la qualité de ce traitement, en appliquant une formule de type `SLA = 1 - (nombre de dossiers pouvant être traités manuellement ÷ nombre d’usagers sur la même période)`.**

> Par exemple, si je dispose d'un community manager pouvant accompagner et débloquer efficacement 10 usagers par jour, avec un service utilisé par 1 000 usagers quotidiens, mon budget d'erreur est de 10 / 1 000 = 1%, ce qui fixe mon SLA à 99 %.


# Données

Les données produites par les usagers dans leurs interactions avec un service numérique ont une forte valeur potentielle. Cette valeur peut être fournie directement, notamment si le logiciel a pour but principal la mise à disposition d’informations fournies par ses usagers. Cette valeur directe peut également être doublée de celle des effets de réseau lorsque le logiciel met en relation plusieurs usagers, et où il vaut alors autant — voire plus — par la communauté qu’il a déjà consolidée que par son essence algorithmique \[Verdier]. Pour garantir la non-réappropriation, il est donc fondamental que cette valeur, qui peut être supérieure à celle du code, ne soit pas détenue par un acteur unique \[[Maurel](https://scinfolex.com/2016/01/15/eriger-le-reseau-des-donnees-personnelles-en-bien-commun/)].

## Publication <a href="#publier-donnees" id="publier-donnees"></a>

Il s’agit d’ériger le réseau des données constituées par les interactions des usagers comme un bien commun à part entière, dans la mesure où la valeur qui peut en être extraite est supérieure à la somme des valeurs extractibles de chacun des points individuels, tout en respectant le droit de l’individu à maîtriser les données qui le concernent \[Bellanger].

**Une contrainte minimale est la mise à disposition des données manipulées sous une licence qui en permet la réutilisation.**

**Recommandation opérationnelle : exporter à intervalles réguliers (et a minima hebdomadairement) sur data.gouv.fr la base de données du service en rendant impossible la réidentification de ses utilisateurs, sous** [**Licence ouverte 2**](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf)**.**

## Clause de repartage

La réutilisabilité de ces données est suffisante pour garantir le statut de communs numériques à des logiciels qui les capturent. Néanmoins, une réappropriation devient possible si un opérateur mal intentionné les met à disposition dans un format peu lisible et se conserve l’exclusivité d’une chaîne d’analyse permettant d’en extraire la valeur.

Par ailleurs, les contributeurs d'un service peuvent être découragés de participer s'ils ont le sentiment que leurs contributions peuvent être réutilisées par des acteurs propriétaires sans compensation, dans la mesure où le choix de la contribution à un commun est souvent un acte militant.

**Dans le cas des services contributifs, la licence sous laquelle les données produites par les usagers sont mises à disposition inclut une clause de repartage.**

**Recommandation opérationnelle : dans la recommandation précédente, utiliser une licence ODbL au lieu d’une Licence ouverte.**


# Statistiques

Au-delà des données fournies volontairement par les usagers, de la valeur peut être extraite par le simple suivi des interactions avec le service numérique. Une analyse statistique descriptive peut en effet permettre d’améliorer la valeur fournie par le service en aidant à déterminer les fonctionnalités à renforcer, celles à améliorer, et celles à abandonner. Étendre des communs numériques sans connaître leur usage revient à étendre un réseau routier sur la simple base de sa carte, sans jamais avoir pu en voir la fréquentation.

Par ailleurs, si ces données ne sont pas mises en partage, un acteur spécifique peut les financiariser sans nécessairement reverser à la communauté qui rend possible l’exécution du service.

## Publication

Les statistiques de fréquentation du service, si elles sont capturées, devraient donc être mises à disposition sous une licence qui en permet la réutilisation.

**Un commun minimal inclut la mise à disposition des statistiques de fréquentation de chaque fonctionnalité du service sous une licence qui en permet la réutilisation.**

**Recommandation opérationnelle : exposer une instance publique du service de suivi Matomo (ou Xiti),** [**configurée**](https://www.cnil.fr/fr/solutions-pour-la-mesure-daudience) **en conformité avec la règlementation CNIL. Préciser que les données offertes par cette instance sont à disposition sous Licence ouverte.**

## Clause de repartage <a href="#ouvrir-stats-repartage" id="ouvrir-stats-repartage"></a>

Néanmoins, une réappropriation devient possible si un opérateur mal intentionné les met à disposition dans un format peu lisible et se conserve l’exclusivité d’une chaîne d’analyse permettant d’en extraire la valeur en les recoupant avec des bases propriétaires. Pour empêcher cela, si la base de données contient des informations détaillées, elle peut être fournie avec une clause de repartage. Ainsi, tout produit dérivé de cette base devrait lui aussi être rendu public et sera donc accessible à la communauté.

**Il est utile que la licence de publication des statistiques de fréquentation comprenne une clause de repartage.**

**Recommandation opérationnelle : dans la recommandation précédente, utiliser une licence ODbL au lieu d’une Licence ouverte.**


# Communication

Les usagers peuvent être mobilisés d’autres manières que dans leur usage habituel du service. On peut par exemple les solliciter pour contribuer ponctuellement aux communs numériques dont ils forment la communauté, pour les promouvoir ou encore pour procéder à un arbitrage référendaire. La capacité de représentation vis-à-vis des contributeurs, des usagers et du public, dans la mesure où elle détermine en grande partie la capacité de contribution et donc le type et l’intensité de la valeur capturée, doit être considérée comme un constituant des services numériques dont la réappropriation par un sous-ensemble de la communauté ou par un tiers mettrait en risque l’opération en commun.

## Contact de la communauté

**Une contrainte minimale est la mise à disposition de tous les contributeurs de moyens de diffuser des informations à la communauté, tout en garantissant un volume limité de sollicitations afin de maximiser la valeur potentielle.**

**Recommandation opérationnelle : permettre aux usagers de fournir leur adresse électronique, les enregistrer dans un outil de diffusion compatible avec le droit européen sur les données personnelles comme** [**SendInBlue**](https://fr.sendinblue.com) **ou** [**Framalistes**](https://framalistes.org) **et s’engager envers les personnes inscrites sur une fréquence maximale d’envoi (1 fois par mois, par semaine…). Mettre à disposition des contributeurs un espace de rédaction collaborative comme** [**Framapad**](https://framapad.org) **pour préparer les envois.**

## Communication extérieure <a href="#ouvrir-diffusion" id="ouvrir-diffusion"></a>

En plus des messages directs, les outils de diffusion que sont les réseaux sociaux peuvent permettre de toucher un public large, pouvant aller au-delà des usagers et des contributeurs. Là encore, la capacité à toucher ce public doit être mise en partage.

**Un commun contributif inclut la mise à disposition des contributeurs de moyens de contacter le public, tout en garantissant une forte pertinence des messages diffusés.**

**Recommandation opérationnelle : rédiger une charte rédactionnelle (**[**exemple**](https://github.com/betagouv/aides-jeunes/wiki/Notre-ton)**), utiliser un système de délégation de compte pour chaque média social utilisé par le service (TweetDeck pour Twitter, Business Manager pour Facebook…) et faire certifier le compte social par l’opérateur du réseau.**


# Marque

Au-delà des contributeurs et de la communauté d’usagers, un troisième cercle d’interaction des communs numériques existe vis-à-vis du grand public. Ces interactions ont lieu non pas directement avec le service (sinon il s’agirait d’usagers), mais avec une marque, qui peut être constituée d’un nom, d’un logo, d’un nom de domaine, d’une charte graphique… Les marques représentent le capital réputationnel des communs numériques. Pour être compatibles avec ce statut, leur bénéfice doit donc être mis en partage et défendu sans réappropriation, comme les autres formes de capital.

## Mise à disposition <a href="#charte" id="charte"></a>

La mise à disposition des éléments constitutifs de la marque est particulièrement importante dans le cas des communs contributifs, puisque l'orientation des contributions se fera en premier lieu par l'usage de ces éléments. Si un acteur a la mainmise sur eux, il pourra réorienter les contributions vers son propre service, potentiellement non opéré comme commun.

**Dans le cas d'un service contributif, les éléments constitutifs de la marque sont protégés juridiquement et mis à libre disposition sous condition du respect d’une charte visant uniquement à protéger le capital réputationnel des communs et non un acteur en particulier.**

**Recommandation opérationnelle : fournir tous les éléments de marque sur un page web, les** [**déposer à l’INPI**](https://www.inpi.fr/fr/services-et-prestations/depot-de-marque-en-ligne) **et adapter la** [**Politique de marque de Wikipédia**](https://meta.wikimedia.org/wiki/Trademark_policy/fr#policy) **pour définir les cas d’usage recommandés et ceux défendus. Les cas défendus sont justifiés par l’explicitation du danger qu’il ferait peser sur le capital réputationnel.**


# Stratégie

Au-delà de la limitation des risques de réappropriation des moyens de produire de la valeur, se pose la question des modalités d’engagement des ressources déjà mises en commun.

## Publication des demandes d'évolution <a href="#ouvrir-demandes" id="ouvrir-demandes"></a>

Dans le cadre d’une gouvernance démocratique, la feuille de route générale du service est théoriquement basée sur les besoins exprimés de la communauté. Pour autant, des arbitrages doivent être menés sur la base des ressources disponibles. Si ces arbitrages avantagent systématiquement un certain type d’acteur, il y a réappropriation de fait des ressources mises en commun dans la mesure où, dans le temps, le service numérique apportera une valeur croissante à certains usagers aux dépens de ceux pour lesquels l’investissement n’a pas pu être effectué. Les modalités de définition des orientations stratégiques doivent donc être considérées comme un constituant du service et soumises à une gouvernance adaptée.

**Une contrainte minimale est la publication des demandes d'évolution provenant des usagers.**

**Recommandation opérationnelle : consolider les retours usager soit directement dans la forge logicielle utilisée par le biais de « tickets » ou « issues », soit sur un outil dédié.**

## Publication des moyens disponibles <a href="#ouvrir-moyens" id="ouvrir-moyens"></a>

Afin de permettre à la communauté de participer correctement à l’arbitrage entre les besoins et les moyens, les ressources limitées et mesurables doivent être accessibles au moins à la communauté, comme par exemple les moyens financiers de la structure qui opère le service.

**Une contrainte minimal est la publication des moyens investis et disponibles pour l'évolution.**

**Recommandation opérationnelle : publier un document budgétaire passé et prévisionnel des moyens investis dans le service.**

## Documentation des arbitrages <a href="#arbitrages" id="arbitrages"></a>

Les modalités d’arbitrage sur la base de ces informations, elles, peuvent être synchrones de type assemblée générale, être déléguées à des mandataires élus, ou encore se reposer sur des outils de décision asynchrones et distribués. Elles doivent dans tous les cas être décrites publiquement et, si l’entité qui opère le service s’est constituée en une structure morale, dans un document statutaire ou règlementaire.

**Une contrainte minimale est la description des modalités de choix d'investissement des moyens disponibles.**

**Recommandation opérationnelle : pour maximiser la participation sans contrainte géographique ni temporelle, privilégier les outils de décision asynchrones et distribués comme** [**Loomio**](https://www.loomio.org) **et des réunions d'information a minima enregistrées et diffusées.**


# Rôles

J'ai défini dans la section [Constituants](/2-constituants) les contraintes minimales à appliquer sur les règles de fonctionnement pour que des services numériques puissent prétendre au statut de communs numériques, contraintes sans lesquelles le risque de réappropriation est trop significatif. Pour autant, la satisfaction de ces conditions ne saurait suffire à en garantir l’effectivité. Les modalités de mise à disposition au public ne sont en effet qu’un des aspects de ce statut. Rappelons-le, la gouvernance tant opérationnelle que stratégique des communs ne saurait être autre que démocratique.

> Par exemple, si le code source d’un service numérique est sous licence avec une clause de repartage mais qu’aucun acteur ne rappelle à l’ordre un réutilisateur en infraction, il s’agit d’une faille permettant la réappropriation tout autant que si la clause d'origine n'existait pas.

Il s’agit donc à présent de définir les modalités d’exercice et d’équilibre du pouvoir entre les différents acteurs qui interviennent sur des communs numériques, non pas dans une logique de territoire mais dans un objectif de garantie de la pérennité de l’outil et de ses valeurs. Ainsi, la gouvernance devra nécessairement être transparente : les différents rôles, ainsi que les modalités de prises de décisions doivent être décrits, et ces dernières doivent être traçables et vérifiables publiquement.

Les différentes parties de cette section présentent les rôles nécessaires à tenir, ordonnés par éloignement d’avec l’usage du service lui-même. Pour chaque rôle, je présente les missions associées et suggère des modalités de rétribution et des formes juridiques associées. Tout comme seules des contraintes peuvent être exprimées sur les règles des constituants et non des règles toutes prêtes, la mise en œuvre concrète de ces rôles dépendra des acteurs rassemblés autour des communs à gouverner. Par exemple, certains acteurs peuvent tenir plusieurs rôles, notamment au début de l’existence du service.


# Communauté

La communauté des utilisateurs des communs numériques est toujours l’ultime décisionnaire. Les modalités de son expression sont à déterminer par chaque commun.

Les différents rôles permettant l’application du commun doivent être eux-mêmes soumis à un examen attentif pour garantir qu’ils l’appliquent. L’instance la plus légitime pour ce faire est l’ensemble de la communauté.

## Risques adressés par le rôle

### Non-respect du commun <a href="#respect-regles" id="respect-regles"></a>

Si les différents acteurs définis dans cette section outrepassent leurs rôles ou inversement ne les remplissent pas correctement, seule la communauté peut (et doit) les remplacer.

C'est pourquoi tous les rôles doivent être tenus de manière transparente vis-à-vis des membres.

### Inutilité du service <a href="#utilite" id="utilite"></a>

En l'absence de communauté, le service numérique commun n'est qu'une coquille vide. La communauté et son implication sont la première mesure de la santé et de l'utilité des communs numériques.

## Forme juridique

La communauté est toujours à considérer comme une multitude \[Colin & Verdier, 2015], et non comme une personne morale ou une classe représentable par un sous-ensemble de ses membres.


# Contributeur

## Risques adressés par le rôle

### Stagnation opérationnelle <a href="#stagnation" id="stagnation"></a>

En l'absence de contributeurs, le service numérique commun n'évolue pas. Cela peut être approprié s'il continue à remplir son rôle vis-à-vis de sa [communauté](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/cd3fb4f227e48485325d069eae93fd04b163f52b/3-roles/1-communaute/README.md), mais peut poser un problème si plus personne en son sein n'est capable de mener les évolutions. Le risque est en effet de basculer vers un modèle propriétaire où un nombre restreint d'entités prennent la main sur les évolutions et en créent un marché.

## Forme juridique

Les contributeurs sont en premier lieu des [utilisateurs](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/cd3fb4f227e48485325d069eae93fd04b163f52b/3-roles/1-communaute/README.md).

Un contributeur ne peut être qu’une personne physique.

Une personne morale ne peut contribuer à des communs qu’indirectement, par l’affiliation de contributeurs individuels, par exemple ses salariés ; ou en étant [sponsor](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/cd3fb4f227e48485325d069eae93fd04b163f52b/3-roles/5-sponsor/README.md) de l'activité des contributeurs par un soutien financier, logistique, réputationnel…

## Rétribution

Dans la plupart des cas, la première des rétributions pour les contributeurs consiste en leur bénéfice à l'utilisation du service numérique commun. Il n'est donc pas nécessaire de prévoir une rétribution spécifique.

Néanmoins, si les contributions ne sont pas reconnues, la motivation des contributeurs peut diminuer. Dans le cas d'un commun contributif, cela peut aboutir à sa disparition. Pour pérenniser la communauté, les contributeurs doivent s'y sentir bienvenus en tant qu'utilisateurs, mais aussi reconnus, voire récompensés, en tant que contributeurs.

Cela peut évidemment se faire par une rétribution financière, par exemple sous la forme d'indemnité, de salaire ou de contrat de prestation. Mais cette reconnaissance peut également provenir, de manière non exclusive, par de la réputation, par exemple en mettant en avant le nom de la personne ayant contribué, ou encore par des pouvoirs décisionnels étendus dans la limite du commun.

L'attribution de ces récompenses peut être faite de manière automatique, par exemple en mettant en avant les plus contributeurs les plus assidus comme le fait [Wikipédia](https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits) ou comme le permet [GitHub](https://docs.github.com/en/github/visualizing-repository-data-with-graphs/accessing-basic-repository-data/viewing-a-projects-contributors).


# Opérateur

Ce rôle vise notamment à organiser et fédérer les contributions. Pour différencier le rôle des [contributeurs](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/3-roles/2-contributeur/README.md) de celui de l'opérateur, la liste des [constituants](/2-constituants) peut encore une fois servir de base pour décrire des actions menées par chacun de ces acteurs.

| Constituant   | Actions des contributeurs                                            | Actions de l'opérateur                                                                            |
| ------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Code source   | Pull request, peer review.                                           | Gatekeeping (tri, feedback, validation, intégration).                                             |
| Usage         | Utilisation du logiciel.                                             | Support.                                                                                          |
| Données       | Utilisation du logiciel.                                             | Promotion (concours…).                                                                            |
| Statistiques  | Utilisation du logiciel.                                             | Analyse et éditorialisation.                                                                      |
| Communication | Animation d’ateliers, création de contenu, inscriptions aux réseaux… | Product management, community management.                                                         |
| Marque        | Promotion publique (publicité, présentations, articles…).            | Mise en relation, démarchage d’espaces de promotion, soutien financier à des initiatives locales… |
| Stratégie     | Remontée d'anomalies, suggestions, vote.                             | Ateliers, recherche utilisateur, RFC.                                                             |

## Risques adressés par le rôle

### Inaccessibilité <a href="#inaccessibilite" id="inaccessibilite"></a>

La mise en partage des ressources ne peut être opérante que si lesdites ressources sont accessibles. Qui garantit la disponibilité du commun ? Par quels moyens ?

**Un rôle de responsabilité opérationnelle du commun doit être tenu, avec des droits de gestion d’accès et de rationnement temporaire pour garantir un accès à tous les membres de la communauté.** {#role-operationnel}\*\*

### Stagnation stratégique <a href="#stagnation" id="stagnation"></a>

La feuille de route générale du service est basée sur les besoins de la communauté. Néanmoins, des arbitrages doivent être menés sur la base des ressources disponibles. Comment arbitrer la [stratégie](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/2-constituants/7-strategie/README.md), ou du moins en faciliter l'établissement, si la communauté n'y arrive pas, en évitant le point mort ?

**Un rôle de responsabilité de produit (*****product ownership*****) doit être tenu, avec un droit d’arbitrage final entre la mise en œuvre de fonctionnalités incompatibles dans leurs effets ou dans leur consommation de ressources.**

### Illégalité des contributions <a href="#illegalite-contributions" id="illegalite-contributions"></a>

Dans le cas des communs contributifs, il peut arriver que du contenu soit mis à disposition en infraction avec le droit. Comment agir pour éteindre le grief ? Qui décide du retrait des contributions ? Qui porte la responsabilité juridique et potentiellement pénale de la mise à disposition ?

**Un rôle d'organisation des contributions et de représentation juridique du commun doit être tenu.**

### Critique

Comme tout service, les communs numériques peuvent être critiqués. Certaines critiques peuvent aller jusqu’à mettre en danger leur capital réputationnel, notamment lorsqu’elles remettent en question leur probité ou leur coût plus que leur utilité. Qui répond aux critiques ? Comment décider auxquelles répondre ?

**Un rôle de représentation du commun doit être tenu.**

## Forme juridique

Dans les communs numériques émergents ou d'envergure limitée, ce rôle peut être tenu directement par certains contributeurs. Néanmoins, le mélange des rôles est délicat et rarement soutenable car il mène les contributeurs portant cette responsabilité supplémentaire à une charge de travail supplémentaire, souvent différente de celle qu'ils mènent habituellement, et qui peut les mettre dans des situations d'arbitrage délicates entre leurs propres contributions et celles d'autres personnes.

En termes de structure, un bon acteur pour tenir ce rôle a une capacité économique pour engager des dépenses et s’ajuster rapidement aux besoins. L’alignement entre gestion et objectifs est supervisé par le [garant](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/3-roles/4-garant/README.md).

Il peut par exemple prendre la forme de :

* SCIC.
* Association à activité économique.
* EPIC.
* [SEM](https://fr.wikipedia.org/wiki/Soci%C3%A9t%C3%A9_d%27%C3%A9conomie_mixte), [SPL](https://fr.wikipedia.org/wiki/Soci%C3%A9t%C3%A9_publique_locale).


# Garant

## Risques adressés par le rôle

### Non-respect du commun <a href="#respect-regles" id="respect-regles"></a>

Nous avons décrit un ensemble de mécanismes juridiques limitant la réappropriation (licence, conditions générales d’utilisation…). Qui active ces mécanismes en cas de suspicion d’infraction ? Selon quelles modalités : mise en demeure, dépôt de plainte… ?

**Un rôle de garant d’application du commun doit être tenu, avec une liste claire des sanctions applicables en cas de non-respect des règles qu’il décrit.**

### Discrimination des contributeurs <a href="#egalite" id="egalite"></a>

Si certains contributeurs ne sont pas accueillis de la même manière que d'autres, il y a à la fois un risque de réduction des contributions, et un risque d'orientation inadaptée dans lequel le service évolue pour ne rendre service qu'au sous-ensemble de la communauté représenté parmi les contributeurs.

**Aucune condition ne peut être exigée pour considérer un utilisateur comme contributeur autre que la contribution, c'est-à-dire l'ajout de valeur sur l'un ou l'autre des constituants, dans le respect du commun associé.**

### Mauvaise gestion des capitaux financiers <a href="#garant-financier" id="garant-financier"></a>

Les capitaux financiers sont les plus versatiles. Ils peuvent être utilisés de manière relativement interchangeable pour de nombreux usages, y compris détournés. Ils peuvent ainsi servir à financer des travaux d’amélioration des communs, tout autant qu’à les défendre juridiquement, qu’à en assurer la promotion… Selon quelles modalités les orientations stratégiques sont-elles transcrites dans la répartition des investissements ? Qui détient la responsabilité de bonne gestion des capitaux financiers ?

**Un rôle de garant financier doit être défini, avec la responsabilité de vérifier la proportionnalité des prélèvements sur les ressources communes avec les objectifs déterminés collectivement.**

## Forme juridique

L'acteur idéal sera en dehors des logiques lucratives, avec pour seul objectif de garantir l’application du commun et son adéquation à la réalité. En effet, le risque de réappropriation augmente avec l’intensité de la recherche du profit financier, puisque la mise en partage des ressources s’oppose à la privatisation des bénéfices qui peuvent en être retirés.

Il peut par exemple prendre la forme de :

* Association.
* Conseil de l’opérateur (bureau d’une association, conseil d’administration d’une SCIC…).
* [Acteur public](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/cd3fb4f227e48485325d069eae93fd04b163f52b/1-concepts/2-action_publique/README.md).

Il est à noter qu'en droit français, une [fondation](https://www.service-public.fr/associations/vosdroits/F31023) ne serait pas appropriée car une fondation n’a vocation qu’à attribuer des ressources sur le long terme, alors qu’on cherche ici une structure capable de prendre des décisions structurantes.


# Sponsor

Certaines organisations peuvent soutenir le service numérique commun sans y contribuer directement, par exemple de manière financière par le don ou la subvention, ou par la réputation en promouvant les usages de l’outil.

## Risques adressés par le rôle

### Manque de moyens

Si le service numérique commun n'a pas de modèle économique propre, l'absence de sponsors peut lui être fatale puisque le rôle d'[opérateur](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/3-roles/3-operateur/README.md) est difficile à tenir sans rétribution financière. Dans le cas des communs contributifs, l'absence d'opérateur rend l'édifice extrêmement fragile puisque la disponibilité du service n'est pas garantie, mettant en péril la capture de valeur par la contribution des [usagers](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/3-roles/1-communaute/README.md), et donc in fine la fourniture du service elle-même.

## Forme juridique

Ces organisations peuvent être de différents types :

* [Acteur public](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/fdae49caf3e6fd5f9e3eb471886f9e40d4d8c879/1-concepts/2-action_publique/README.md).
* Acteurs à but non-lucratif de droit privé (association, fondation…).
* Acteurs à but lucratif de droit privé.

## Rétribution

Tout comme pour les contributeurs, il est utile pour la pérennité de leur soutien que les sponsors se sentent reconnus pour leur participation. Dans tous les cas, ils peuvent être rétribués en réputation par la mise en avant de leur nom et logo. Ils peuvent également être rétribués en pouvoir décisionnel par une participation à certains organes de gouvernance. Dans ce cas, il faut faire attention au respect du commun afin de s'assurer que le soutien ne prenne pas plus d'importance que la contribution.


# Exemple : Wikipédia

Wikipédia est une encyclopédie universelle multilingue dont le contenu est rédigé par ses lecteurs. Wikipédia a pour objectif d’offrir un contenu librement réutilisable, objectif et vérifiable, que chacun peut modifier et améliorer. Chaque instance nationale pouvant disposer de ses propres règles, cet exemple sur focalise sur la version française, accessible à l’adresse fr.wikipedia.org.

Le commun de Wikipédia France est résumé sur sa page d’accueil :

> Wikipédia est définie par des [principes fondateurs](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Principes_fondateurs). Son contenu est sous [licence Creative Commons BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr). Il peut être [copié et réutilisé sous la même licence](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Citation_et_r%C3%A9utilisation_du_contenu_de_Wikip%C3%A9dia), sous réserve d'en respecter les conditions.

Chacun peut publier immédiatement du contenu en ligne, à condition de respecter les règles essentielles établies par la [Fondation Wikimedia](https://wikimediafoundation.org/wiki/Terms_of_Use/fr) et par la communauté ; par exemple, la [vérifiabilité du contenu](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:V%C3%A9rifiabilit%C3%A9), l'[admissibilité des articles](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Crit%C3%A8res_d%27admissibilit%C3%A9_des_articles) et [garder une attitude cordiale](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:R%C3%A8gles_de_savoir-vivre).

On voit l’importance accordée à la communauté, mais aussi aux principes politiques qui la gouvernent, avec une hiérarchie de normes (principes, règles, recommandations) édictées et évolutives (à l’exception des principes, qui sont le fondement du commun).

## Code source

Le logiciel principal qui permet la publication et la modification du contenu de l'encyclopédie est MediaWiki. Son code source est disponible sur plusieurs plateformes, et [on peut voir](https://github.com/wikimedia/mediawiki/blob/master/COPYING) que la licence associée est la GNU *General Public License* version 2. Cette licence est une licence libre classique avec une clause de repartage. Les suggestions de modification sont traitées par le biais d'une *pull request* et d'une revue par les pairs sur gerrit.wikimedia.org. Ce fonctionnement répond donc bien aux contraintes listées dans le chapitre précédent.

## Usage

Les conditions générales d'utilisation de Wikipédia sont les mêmes pour toutes les variantes linguistiques. Voici un extrait du résumé en français :

> Vous êtes libre de lire nos articles et autres médias, gratuitement ; réutiliser nos articles et autres médias sous licences libres ; contribuer à et modifier nos différents sites et Projets sous licences libres.
>
> Sous les conditions suivantes :
>
> * Responsabilité — Vous êtes responsables de vos modifications (puisque que nous ne faisons qu'héberger votre contenu).
> * Courtoisie — Vous restez poli, courtois et respectueux, et vous ne vous livrez pas à des attaques contre les autres personnes.
> * Comportement régulier — Vous ne violez pas les règles sur le copyright ou le droit d'auteur, et ne commettez pas d'actions délictueuses ou inappropriées.
> * Pas de nuisance — Vous ne cherchez pas à porter préjudice à notre infrastructure technique.
> * Conditions d'utilisation et règlement — Vous adhérez aux Conditions d'utilisation ci-dessous aux règlements applicables de la communauté quand vous visitez nos sites ou que vous participez à nos communautés.

Ces conditions générales répondent donc exactement aux contraintes exprimées dans le [chapitre associé](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/2-usage/README.md) : pas de limitation d'usage autre que celles nécessaires à l'opération du service et à la prévention des actes visant à réduire la capacité d'autres usagers.

## Données fournies par les usagers

Toutes les contributions des usagers sont mises à disposition sous une licence Creative Commons imposant l'attribution des contributions à son auteur et le repartage sous conditions identiques (licence [CC-BY-SA-3.0](https://creativecommons.org/licenses/by-sa/3.0/deed.fr)).

Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/3-donnees/README.md) sont remplies.

## Statistiques

Les statistiques de fréquentation sont publiquement accessibles sur [stats.wikimedia.org](https://stats.wikimedia.org/#/fr.wikipedia.org). On peut notamment y voir la répartition géographique des accès, les évolutions du contenu, du nombre et des types de contributions… Les données sont mises à disposition sous une licence CC0 (domaine public).

Les données détaillées, qui peuvent contenir des données personnelles telles que l'adresse IP, [sont accessibles](https://wikitech.wikimedia.org/wiki/Analytics/Data_access) uniquement à certains mandataires de la communauté authentifiés.

Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/4-statistiques/README.md) sont donc remplies.

## Moyens de communication

La communication au nom du service est assurée par la Wikimedia Foundation (organisation de bienfaisance régie par le paragraphe 501-c-3 du code fiscal des États-Unis) et Wikimédia France (association loi 1901 de droit français). Des pins, badges, et autocollants sontpar exemple édités et distribués par Wikimédia France. Cette structure étant régie par le droit des associations, son fonctionnement est régi par des [statuts](https://www.wikimedia.fr/documents-officiels/statuts-de-lassociation/) publics et son conseil d'administration est élu. De même, les administrateurs de la Foundation sont [élus par tiers](https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/Board_elections), par l'ensemble de la communauté. Ces personnes ont donc accès aux moyens de communication pour représenter la communauté et agir en son nom.

Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/5-communication/README.md) sur la représentativité des messages passés est ainsi assurée par l'aspect démocratique de l'élection et du renouvellement du mandat.

## Marque

La Wikimedia Foundation est dépositaire de la marque Wikipédia, et la [met à disposition](https://foundation.wikimedia.org/wiki/Trademark_policy) sous une politique de marques publique. Le droit d'usage est acquis lorsque l'objectif poursuivi est :

* Représenter sincèrement un site Wikimédia.
* Documenter factuellement des actualités liées à Wikimédia.
* Créer des œuvres artistiques, littéraires ou politiques.
* Créer des liens vers les sites Wikimédia.

Et inversement, l'usage est interdit lorsqu'il s'agit de créer des contrefaçons ou de tromper d'une quelconque manière.

Ces contraintes d'usage de la marque sont donc au bénéfice de la communauté, qui est protégée légalement d'un détournement de ses contributions et d'un mésusage du capital réputationnel accumulé. Les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/6-marque/README.md) sont donc remplies.

## Stratégie

Les « résolutions » prises par la Wikimedia Foundation sont des orientations stratégiques majeures. Elles sont publiques et [documentées](https://foundation.wikimedia.org/wiki/Resolutions), et sont prises par le conseil d'administration élu selon les conditions décrites plus haut. Les modalités de prises de décision en vigueur sur la Wikipédia francophone sont elles aussi [publiques](https://fr.wikipedia.org/wiki/Wikipédia:Système_de_prise_de_décision) : un changement de règle peut être demandé par n'importe quel contributeur, et la prise de décision est faite au consensus, et au vote à défaut de consensus.

Par la publicité des comptes rendue obligatoire par les statuts juridiques des structures opérant le service, par la possibilité laissée à tout contributeur d'ouvrir une discussion menant à une décision, et par la documentation des règles de décision, les [contraintes](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/d1a1f630dfb7ce3b53326c0929bdf5890c7cc3ef/2-constituants/7-strategie/README.md) applicables à la stratégie d'évolution sont remplies.

## Synthèse

L'application du cadre d'analyse sur l'intégralité des constituants du service numérique fr.wikipedia.org permet de caractériser ce en quoi sa gouvernance relève des services numériques communs, au-delà de la simple analyse du code source. Ces conclusions peuvent être résumées dans un tableau :

|           Constituant          |                                                                Règle                                                               |
| :----------------------------: | :--------------------------------------------------------------------------------------------------------------------------------: |
|   Code source (de Mediawiki)   |                                 Licence GPL-2. Pull request, peer review sur gerrit.wikimedia.org.                                 |
|          Droit d’usage         |                                CGUs autorisant l’usage tant qu’il n’empêche pas les autres usagers.                                |
| Données créées par les usagers |                                                            CC-BY-SA-3.0.                                                           |
|         Données d’usage        |                                               Statistiques publiquement accessibles.                                               |
|     Moyens de communication    |                 Élection des personnes pouvant représenter le service via Wikimedia Foundation et Wikimedia France.                |
|             Marque             | La Wikimedia Foundation est dépositaire de la marque Wikipédia et l’offre sous une politique de marques qui protège la communauté. |
|      Modalités d'évolution     |          Résolutions publiques du conseil d’administration élu. Consensus et vote à défaut pour les évolutions de règles.          |

## Modalités d'action

Par ailleurs, les modalités de contribution et d'animation sur chaque constituant peuvent également être décrites.

| Constituant  | Actions des contributeurs individuels                                                                              | Actions des [administrateurs](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Administrateur)                                                                                              |
| ------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Usage        | Connexion sur wikipedia.org.                                                                                       | Page « actualités », [article labellisé du jour](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal)…                                                                       |
| Code source  | Pull request, peer review sur [gerrit.wikimedia.org](https://gerrit.wikimedia.org).                                | [Traitement (tri, orientation…) des sollicitations d’intégration](https://github.com/wikimedia/mediawiki/pull/66).                                                                      |
| Données      | Lien « éditer » sur chaque page.                                                                                   | [Suspension de compte, annulation de modifications](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Administrateur#Fonctionnalit.C3.A9s_suppl.C3.A9mentaires_qui_lui_sont_accord.C3.A9es). |
| Statistiques | Usage                                                                                                              | Opération de stats.wikimedia.org                                                                                                                                                        |
| Communauté   | Pages [Premiers pas](https://fr.wikipedia.org/wiki/Aide:Premiers_pas).                                             | [Concours annuels](http://wikilovesmonuments.fr) et [événements](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:WikiCheese) organisés par [Wikimedia France](https://www.wikimedia.fr).   |
| Marque       | Recommandation d’usage, citation, hyperliens.                                                                      | Pins, badges, autocollants édités et distribués par Wikimedia France.                                                                                                                   |
| Stratégie    | [Consensus et vote à défaut.](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Syst%C3%A8me_de_prise_de_d%C3%A9cision) |                                                                                                                                                                                         |


# Exemples contribués

Ces exemples prennent la grille d'analyse décrite par ce document, et l'appliquent à des cas réels pour en vérifier et en démontrer l'utilité.

Tous ne sont pas des communs numériques complets, mais ont fortement travaillé à l’ouverture et la transparence de leur gouvernance. L'application de la grille d'analyse permet d'ailleurs de poser la question de l'existence de communs comme un spectre plutôt que comme un type d'objets numériques à part entière.

Ces analyses sont des contributions tierces dont le contenu n'est pas confirmé par l'auteur.


# Docker

Docker est un logiciel libre de gestion de paravirtualisation qui permet d’isoler et d’allouer dynamiquement des ressources physiques. Il garantit la portabilité d’application et de leur dépendances à l’aide de containers et s’impose comme un standard de facto.

Docker n’est pas un commun : la société commerciale Docker Inc garde les rôles clef de la gouvernance des différents produits et services, même si elle est ouverte et transparente. Cette positione est assumée, comme l'illustre le rôle du Benevolent dictator for life (BDFL) assuré par le fondateur Solomon Hykes.

## Produits et services

### hub.docker.com

Service propriétaire de Docker Inc qui regroupe des contributions de la communauté. Il existe au moins [une alternative](https://github.com/nathanleclaire/tarzan), mais qui perd l’intérêt du service centralisé.

* Images communautaires : possible pour tous avec inscription au préalable.
* Images officielles gérées par docker.com avec un processus d’habilitation <partners@docker.com> et une équipe de [mainteneurs](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) (à noter, d’une société tierce : [infosiftr.com](http://www.infosiftr.com)).

### Le logiciel libre Docker

* Une gouvernance du projet, non démocratique, mais transparente et ouverte à des extérieurs de Dockers Inc via GitHub. GitHub est l’outil de collaboration et de travail, pas d’un simple dépôt de code ouvert a posteriori.
* Une gouvernance générale de tous les projets avec un [*governance advisory board*](https://docs.docker.com/opensource/governance/dgab-info/)qui reprend 6 principes d’une gouvernance ouverte.
* Un détail des rôles et une [consolidation automatique](https://github.com/docker/opensource/blob/master/MAINTAINERS) des mainteneurs des différents projets.

### La communauté Docker

La communauté gère essentiellement la documentation, les forums, et le site [github.com/docker/docker.github.io](https://github.com/docker/docker.github.io) avec code et contenu disponible sous apache 2.0

## Analyse

Pour appliquer la grille de lecture proposée dans ce document (version 2017) :

| **Constituant**             | **Modalités de contribution**           | **Modalités d’animation**                                                          | **Commun**                                                                                      |
| --------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Usage (hub.docker)**      | Utilisation du hub : docker pull        | Images officielles vs personnelles                                                 | Plateforme mise à disposition par Docker Inc et gouvernance partagée sur les images officielles |
| **Code source (docker CE)** | Pull Request                            | Fichier MAINTAINERS                                                                | Hébergé sur GitHub                                                                              |
| **Données (hub.docker)**    | Création de repository sur le hub       |                                                                                    |                                                                                                 |
| **Communauté**              | Documentation rédigée par la communauté |                                                                                    | Contrôlée par Docker Inc, mais sous licence apache 2.0                                          |
| **Marque**                  |                                         | La commande docker pointe naturellement vers le hub docker propriété de Docker Inc | Propriété de Docker Inc                                                                         |
| **Stratégie**               |                                         |                                                                                    | MAINTAINERS.md : Docker Inc garde le dernier mot                                                |
| **Acteur**                  | Individus                               |                                                                                    | Docker Inc                                                                                      |


# Node.js

**Cet exemple n'est pas complet.** Votre contribution pour appliquer la grille d'analyse est bienvenue !

*Node.js est un moteur d’exécution du langage de programmation JavaScript.*

*En tant que logiciel libre, il a rapidement été utilisé par une large communauté de développeurs. En 2014, une polémique éclate puis enfle autour d’un manque de réactivité de l’entreprise détentrice de la marque Node.js. Un groupe des contributeurs principaux décide de « forker », c’est-à-dire de dupliquer le code et de créer une plateforme alternative, io.js. Cette alternative va jusqu’à* [*créer une identité graphique*](http://designhooks.com/case-study-building-logo-brand-indentity-io-js/) *forte et indépendante. La communauté est rapidement divisée entre un logiciel qui évolue rapidement mais qui a une base d’utilisateurs plus faible et peu de visibilité et un logiciel avec un historique mais avançant au ralenti. Les inquiétudes sont fortes sur le futur du produit. Il faudra plusieurs mois avant qu’un commun soit* [*proposé*](https://github.com/nodejs/node/issues/978)*. Ce commun comprend la création d’une nouvelle entité, la* [*Node Foundation*](https://nodejs.org/en/foundation/)*, qui est dépositaire de la marque Node.js. Seule la mise en œuvre de ce commun permet la* [*réunion*](https://github.com/nodejs/node/issues/1664#issuecomment-101828384) *des deux projets. Aujourd’hui, Node.js est l’une des plateformes de développement les plus populaires, en* [*passe de dépasser Java*](http://blog.builtinnode.com/post/node-js-will-overtake-java-within-a-year-analysis)*.*


# Mozilla

La gouvernance de nombreux projets portés par la Fondation Mozilla est mutualisée et explicitée sur une [page dédiée](https://www.mozilla.org/en-US/foundation/licensing/).


# Métaphores

Ces métaphores ont pour objet d'aider à comprendre les enjeux et tensions des communs numériques à travers l'exemple de communs matériels.

## Potager partagé <a href="#potager-partage" id="potager-partage"></a>

Soit un potager partagé. L’espace est mis à disposition par la mairie à l’ensemble des résidents du quartier. L’objectif annoncé et clair est l’autosuffisance alimentaire du quartier, avec toute latitude laissée aux résidents pour gérer le potager. L’un des résidents, au lieu d’utiliser son espace pour se nourrir, utilise des engrais et vend sa récolte à d’autres résidents. Ceux-ci, n’ayant pas la main verte, lui offrent leur espace. Le jardinier obtient ainsi une superficie grandissante, et vend de plus en plus de fruits et légumes. Tant, en fait, qu’au bout de deux ans il cultive 95% de la surface du potager « partagé », et que seules trois autres résidentes ont appris à cultiver.

Alors, l’autosuffisance alimentaire du quartier est-elle garantie ?

La mairie est-elle légitime à reprendre le contrôle du terrain ?

Les habitants des autres quartiers qui voient ainsi leurs impôts financer un jardinier qui, certes, nourrit son quartier, sont-ils pour autant fondés à lui demander une contrepartie ?

## Chemin de randonnée <a href="#chemin-de-randonnee" id="chemin-de-randonnee"></a>

Un chemin de randonnée balisé par la FFRandonnée sur lequel personne ne marche pendant deux ans devient inutilisable pour tout le monde. Un cafetier décide d’établir une buvette sur l’un des embranchements d’un sentier entretenu depuis 20 ans et l’autre sentier, qui mène à un lac, est progressivement déserté.

Le cafetier est-il responsable de la perte d’accès au lac ?

Et s’il construit une piscine payante avec l’argent gagné par la buvette pour démontrer que le lac n’a aucun intérêt ?

Est-il acceptable que la FFRandonnée doive investir en entretien et en promotion de l’autre sentier pour compenser l’intérêt du cafetier qui n’a pu, en premier lieu, s’installer à cet endroit que grâce au travail continu et en grande partie involontaire des marcheurs ?


# Références

Les publications suivantes sont référencées tout au long de cet ouvrage :

* Aigrin, 2002 : [A framework for understanding the impact of GPL copylefting vs. non copylefting licenses](http://flosshub.org/system/files/aigrain2.pdf) (traduction : [Cadre de reflexion pour comprendre l'impact des licences libres du type “copyleft”](http://www.univ-paris1.fr/diplomes/master-droit-du-numerique/bibliotheque-numerique-du-droit-de-ladministration-electronique/tic/informatique/logiciel-libre/cadre-de-reflexion-pour-comprendre-limpact-des-licences-libres-du-type-copyleft/)).
* Bellanger, 2014 : [Principes et pratiques des données personnelles en réseau](http://pierrebellanger.skyrock.com/3231110655-Principes-et-pratiques-des-donnees-personnelles-en-reseau.html).
* Colin & Verdier, 2015 : [L'âge de la multitude](http://www.armand-colin.com/lage-de-la-multitude-2e-ed-entreprendre-et-gouverner-apres-la-revolution-numerique-9782200601447).
* Coriat et al., 2015 : [Le retour des communs](http://www.editionslesliensquiliberent.fr/livre-Le_retour_des_communs-9791020902726-1-1-0-1.html).
* Coriat, 2017 : [Conférence Le commun et le numérique](http://www.sciencespo-aix.fr/agenda/?date=2017-05) du 31/05/2017 à Sciences Po Aix.
* Dardot, 2017 : [Conférence Le commun et le numérique](http://www.sciencespo-aix.fr/agenda/?date=2017-05) du 31/05/2017 à Sciences Po Aix.
* Maurel, 2016 : [Ériger le réseau des données personnelles en bien commun](https://scinfolex.com/2016/01/15/eriger-le-reseau-des-donnees-personnelles-en-bien-commun/)
* Rogers, 1962 : [Diffusion of Innovations](https://books.google.fr/books?id=v1ii4QsB7jIC).
* Verdier & Murciano, 2015 : [Les communs numériques : éléments d’économie politique](http://events.chairefdd.org/wp-content/uploads/2016/04/CAHIER_FDD_69.pdf).

## Bibliographie <a href="#bibliographie" id="bibliographie"></a>

Ces ouvrages sont une lecture recommandée pour aller plus loin :

* Dardot & Laval, 2014, [Commun](http://www.editionsladecouverte.fr/catalogue/index-commun-9782707169389.html).
* Ostrom, 1990 : [Governing the commons](http://www.wtf.tw/ref/ostrom_1990.pdf).


# English abstract

This article suggests decomposing digital services into a series of components on which to apply rules for sharing in order for them to operate as digital commons through the resulting governance.

These components are: source code, usage rights, data produced by users, usage data, means of communication, brand, and modes of evolution. Missing to appropriately share any of these components opens up loopholes that enable the reenclosure of resources necessary to the operation of the service as a digital common in the medium or long term.

For each of these component, this article defines basic constraints to be applied on the rules to guarantee their sustainability. Additional constraints are also suggested for services whose value depends on the active contribution of their community, since this contribution capacity is directly correlated to the time invested by its members and is therefore a rival resource. This framework highlights aspects of digital services that are often considered peripheral and facilitates the definition of a governance appropriate for a sustainable community operation.


# Remerciements

Ces personnes ont permis à cet ouvrage d'être ce qu'il est aujourd'hui :

* David Bruant
* Henri Verdier
* Laurent Bossavit
* Laurent Joubert
* Mauko Quiroga
* Philippe Honigman
* Sandra Chakroun
* Vincent B


# Changelog

Ce document évolue dans le temps. Le journal des modifications ci-dessous décrit ses évolutions et les regroupe sous des numéros de version suivant la spécification [SemVer](https://semver.org/lang/fr/), afin de permettre d'en référencer des versions spécifiques.

### v1.2.0 (19/08/2021)

* Fusionne les parties « Gouvernance » et « Acteurs » en une seule section « Rôles », organisée autour des risques adressés par les rôles (pourquoi il faut les tenir) et des formes juridiques possibles (qui peut les tenir).
* Éclate le constituant Données en Données et Statistiques au vu du faible nombre de cas réels où les statistiques sont ouvertes.
* Renomme et précise le constituant Communauté en Communication.
* Précise le constituant Stratégie.
* Réécrit l'introduction de la partie Constituants et y intègre la grille de synthèse.
* Renomme les recommandations « pour les acteurs publics » en « opérationnelles », car il n'y a que peu de cas où elles sont réellement spécifiques aux acteurs publics.
* Réorganise les pages en groupes.
* Ajout du terme « code of conduct ».
* Ajout de l'ops dans le constituant Code source.
* Ajout du changelog.

#### v1.1.2 (09/02/2020)

* Corrige la forme de l'analyse de Docker.

#### v1.1.1 (15/12/2018)

* Reformulation mineure.

### v1.1.0 (25/02/2018)

* Modifie le calcul du SLA.

## v1.0.0 (08/01/2018)

* Première publication.

## v0 (août 2017)

* Première présentation interne à la DINUM.


# Format et PDF

Ce livre est mis à disposition par le biais d'un [GitBook](https://www.gitbook.com), un système d'édition basé sur le logiciel de gestion de version collaboratif Git. Cela signifie que vos contributions sont bienvenues et espérées ! Si vous trouvez des fautes, des formulations trop lourdes, ambiguës, ou encore si vous avez des retours d'expérience ou des recommandations alternatives, [corrigez le texte](https://github.com/MattiSG/construire-communs-numeriques) directement (si vous ne savez pas comment faire, passez par un commentaire via le bouton `+` qui apparaît quand vous survolez un paragraphe avec votre souris).

## Téléchargement

Vous pouvez lire ce livre [en ligne](https://communs.mattischneider.fr) ou le télécharger au format [PDF](https://github.com/MattiSG/livre-blanc-communs-numeriques/tree/e12289ba2293c998752c05bac6941811df5d2739/assets/construire_communs_numeriques_v1_2_0.pdf).


# Licence

Ce livre vous est offert sous une licence [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.fr). Cela signifie que vous pouvez le lire, le distribuer, le citer, le modifier et l'adapter comme bon vous semble, y compris de manière commerciale, tant que :

* Vous accompagnez l’utilisation d’un lien vers `communs.mattischneider.fr`.
* Le contenu que vous créez sur la base de celui-ci est sous une licence similaire, c’est-à-dire qu’il n’interdit à personne de réutiliser vos améliorations.

Pour plus de détails, vous pouvez lire la [licence complète](https://creativecommons.org/licenses/by-sa/4.0/deed.fr).


