Un logiciel libre
et ce qui le fait vivre

Comment ça marche

Une licence libre dit ce que chacun a le droit de faire du code. L’observatoire a choisi l’AGPLv3, pour trois raisons.

Elle protège le partage. Avec la GPL, la licence de GeoNature, celui qui modifie le logiciel et le diffuse doit publier ses modifications. Or un observatoire ne se diffuse pas : on le consulte sur un site. Une structure pourrait l’améliorer et l’exploiter en ligne sans jamais partager ses améliorations. L’AGPL comble ce manque. Dès qu’une version modifiée est accessible en ligne, ses modifications doivent être publiées. Ce que l’un améliore profite à tous.

Elle va avec le modèle. Aucune version fermée, plus riche, n’existe à côté du code libre. La page « Le modèle » trace la ligne entre ce qui est gratuit et ce qui se paie.

Elle s’accorde avec l’écosystème. GeoNature et GeoNature-atlas sont sous GPLv3, et les deux licences sont compatibles.

Puis-je l’installer seul ? Oui, à partir de la sortie publique, en mars 2027, sans rien demander ni payer. Le code sera publié dès décembre 2026, mais la procédure d’installation arrive en mars, une fois éprouvée par une première installation sans l’auteur. Il faut une base GeoNature, ou une autre source d’observations, un serveur, et le temps de suivre la procédure. Sans GeoNature, il faut aussi une copie des référentiels taxonomique et géographique. Si vous préférez ne rien gérer, un service d’hébergement et de mise en service existe aussi.

Pour votre informaticien

L’AGPLv3 vous oblige à deux choses, dans deux cas. Si vous redistribuez le logiciel, transmettez son code source et sa licence. Si vous modifiez le code et servez la version modifiée à des visiteurs, proposez-leur le code source de votre version, par exemple par un lien vers votre dépôt. Utiliser le code sans le modifier ni le redistribuer ne crée aucune obligation.

Le droit d’auteur reste à Mathias Broutin, son auteur, et chaque contributeur garde le sien sur sa part.

La licence du code ne touche pas vos données : elles restent sous la licence que vous leur donnez. Les photos et les textes venus d’autres sources gardent leur licence et leur auteur, affichés sur la fiche.

Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Le code n’est pas encore public : il le sera en décembre 2026.
• La procédure d’installation n’est pas encore publique : elle sera éprouvée en février 2027, lors d’une première installation sans l’auteur, et publiée en mars 2027.
• Il ne calcule pas la sensibilité d’une source qui n’en a pas : sur une base d’import, chaque observation suit la déclaration de sa source.

Ce qui est gratuit et ce qui se paie : Le modèle.

Comment ça marche

Le logiciel et le service sont deux choses distinctes.

Le logiciel est libre. Son code sera publié en décembre 2026, sous licence AGPLv3. Chacun pourra le télécharger et le modifier, puis l’installer sur son serveur ou en confier l’hébergement à qui il veut dès la sortie publique, en mars 2027, sans rien payer ni rien demander. La procédure d’installation aura alors été éprouvée par une première installation par un tiers, en février 2027.

Le service se paie. On n’achète pas le droit d’utiliser le logiciel, on achète de ne pas avoir à s’en occuper :

• L’hébergement et l’exploitation de votre observatoire.
• Sa mise en service.
• Le raccordement d’une nouvelle source.
• La formation.

Dans la durée, une convention annuelle prendra en charge l’entretien du logiciel et de vos observatoires, le support et des évolutions choisies avec vous.

Une règle fixe la frontière, que la page « Le modèle » appelle la ligne de partage : tout ce que contient le dépôt est gratuit, y compris l’administration et les scripts. Ce qui réclame une machine ou du temps se paie.

Les tarifs seront publiés à la sortie publique, en mars 2027. D’ici là, écrivez-nous : nous étudions chaque demande.

Une fonction qui vous manque peut aussi se financer, seul ou à plusieurs. Elle profite alors à toutes les installations. La feuille de route donne, pour chaque évolution, son estimation en jours de travail.

Pour votre informaticien

Installer vous-même ne coûte que votre serveur et votre temps : celui de l’installation, puis celui de l’entretien (montées de version, TaxRef chaque année, évolutions de GeoNature). Il vous faut :

• Une base PostgreSQL avec PostGIS (GEOS 3.12 au moins) : une copie de votre GeoNature, une base dédiée, ou une base neuve dans laquelle on copie les référentiels taxonomique et géographique.
• Un serveur Linux qui fait tourner un conteneur.
• Le temps de suivre la procédure d’installation, publiée en mars 2027.

Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Aucun tarif n’est publié avant mars 2027.
• La procédure d’installation n’est pas encore publique : elle arrive à la sortie publique, en mars 2027.
• Le temps qu’une installation demande à votre équipe n’est pas encore mesuré.

La suite : Comment l’acheter : convention, commande, marché public ?

Comment ça marche

Aujourd’hui, un seul développeur maintient l’observatoire : Mathias Broutin, de Mémoire du Vivant. C’est un risque. Trois choses le réduisent.

La licence. En décembre 2026, le code sera publié sous AGPLv3. Votre observatoire ne dépendra plus d’une seule personne pour exister. Son entretien, lui, doit être financé. Un autre prestataire, votre informaticien ou une autre structure pourra le reprendre, l’installer et le faire évoluer.

La documentation. Elle est réécrite pour qu’un opérateur qui ne connaît pas le code installe un observatoire : prérequis, comptes de base de données, étapes de mise en service, vérifications. Un essai à blanc, mené en ne lisant qu’elle, a joué la plus grande partie de la procédure et en a nommé les trous. La documentation sera publiée à la sortie publique, en mars 2027.

La preuve. En février 2027, une première structure installera l’observatoire sans son auteur. Ce qui coincera ce jour-là sera corrigé avant la sortie publique, en mars 2027.

Pour l’organisation, une feuille de route ouverte est proposée. Le financement donne une voix, pas une propriété sur le code.

Pour votre informaticien

Le dépôt contiendra le code de l’application, les scripts SQL qui fabriquent les vues et la couche de diffusion, et les procédures d’exploitation : mettre en service, rafraîchir les vues, revenir en arrière.

Les règles qui protègent les données sont gardées par des tests automatiques, et les choix d’architecture sont documentés avec leurs raisons.

Le dépôt public part de zéro, sans l’historique de développement.

Le droit d’auteur reste à Mathias Broutin, son auteur. Chaque contributeur garde le sien sur sa part.

Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Un seul mainteneur aujourd’hui, sans second développeur formé au code.
• Le code n’est pas encore public : il le sera en décembre 2026.
• Aucune instance de décision n’est encore instituée.

Ce qui fait vivre le code : Le modèle.

Comment ça marche

Le code. Aujourd’hui, un observatoire hébergé par Mémoire du Vivant suit la version principale du code, et se redéploie à chaque nouvelle version. On peut aussi geler un observatoire sur une version donnée, mais il ne reçoit alors plus aucun correctif.

Ce qu’il prépare. À chaque mise à jour des chiffres, les vues se reconstruisent à partir de leurs scripts. Une évolution de leur forme arrive donc au passage suivant, sans geste à la main.

Un ordre à respecter. Certaines évolutions se font par des scripts, dans un ordre documenté. Par exemple, une version qui lit la couche de diffusion ne se déploie qu’une fois la couche préparée et les sources déclarées.

Ce qui se sauvegarde. Votre base reste la vôtre. Tout ce que l’observatoire prépare se recalcule à partir d’elle. Seuls les réglages de l’administration, c’est-à-dire la configuration, les textes d’aide et les réglages de carte, ne se reconstruisent pas.

Aujourd’hui. Aucune sauvegarde planifiée de ces réglages ne tournait au 20 octobre 2026, et l’administration ne sait pas encore les exporter. Une sauvegarde minimale de la configuration est prévue avant février 2027.

Pour votre informaticien

• Déploiement depuis la branche principale du dépôt, en conteneur, à chaque nouvelle version. Après une évolution des vues, rejouer la préparation de la couche puis le recalcul, dans cet ordre.
• À sauvegarder de votre côté : les tables de réglage du schéma de l’observatoire. Le reste se reconstruit.
• Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Pas de sauvegarde planifiée des réglages : elle est prévue avant février 2027.
• Pas d’export ni d’import des réglages depuis l’administration.
• Pas de procédure de mise à jour écrite pour un installateur tiers.
• Pas de journal des réglages qui dirait qui a changé quoi.

La suite : Si nous arrêtons ou changeons de prestataire, que gardons-nous ?

Comment ça marche

Ce que vous achetez. Un service, jamais le droit d’utiliser le logiciel, qui est libre. On achète de ne pas avoir à s’en occuper : l’hébergement et l’exploitation d’un observatoire, sa mise en service, le raccordement d’une nouvelle source, la formation.

Qui contracte. Mémoire du Vivant, nom commercial de l’entreprise individuelle de Mathias Broutin. Les devis, les factures et les contrats portent aussi son nom, la mention « EI » et son numéro SIRET.

Le chemin. Vous nous écrivez, vous recevez un devis. Puis, selon votre structure, vous passez un bon de commande, une convention ou un marché. Un acheteur public reçoit la facture sur Chorus Pro, le portail de l’État par lequel passent toutes les factures adressées au secteur public : nous l’y déposons, et votre service la traite comme les autres. Il suffit de nous donner les références qu’il demande, son SIRET et, s’il en a, un code service ou un numéro d’engagement.

Qui porte le financement. Votre structure, qui achète le service. Elle le règle sur son budget, ou l’inscrit dans un projet qu’elle fait déjà financer, auprès de l’État en région, d’une agence de l’eau, d’un département, d’un programme européen, etc.

L’entretien dans la durée. Après la mise en service, une convention annuelle d’entretien prendra le relais : la maintenance du logiciel et de vos observatoires, le support et des évolutions choisies avec vous. Son détail et la grille des tarifs seront publiés à la sortie publique, en mars 2027.

L’accessibilité, pour un acheteur public. Un acheteur public qui met un outil en ligne doit le rendre accessible. Aucun audit d’accessibilité n’a été réalisé sur l’observatoire. La mise en conformité au RGAA figure parmi les évolutions à financer de la feuille de route.

Pour votre informaticien

• Aucune licence d’utilisation à acheter : le code est sous AGPLv3, les factures ne portent que sur des services.
• Les mentions de la facture (nom, « EI », SIRET) suivent le décret n° 2022-725.
• Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Aucun tarif n’est publié avant mars 2027.
• Aucune référence en production ne peut encore être nommée.
• Aucun audit d’accessibilité RGAA n’a été réalisé.

La suite : Écrivez-nous

Comment ça marche

En jours, jamais en monnaie. Chaque évolution est d’abord spécifiée, puis estimée en jours de travail. Une structure sait exactement ce qu’elle finance.

Seul ou à plusieurs. Une structure peut financer une évolution à elle seule, ou se joindre à d’autres. Chacune est nommée si elle le souhaite, et la somme qu’elle apporte reste confidentielle. Aucune n’en devient propriétaire.

Livrée, elle rejoint le code de tous. L’évolution entre dans le code libre : toutes les installations en profitent, et chacun peut la faire évoluer à son tour.

Ce qui est à financer. La feuille de route présente les évolutions ouvertes, chacune avec le public qu’elle sert et son estimation en jours. Une idée qui n’a pas encore de financement se propose aussi : dites quel besoin elle sert, pour qui, et quelle structure pourrait la porter.

Qui porte le financement. Votre structure. Elle règle le service sur son budget, ou l’inscrit dans un projet qu’elle fait déjà financer, auprès de l’État en région, d’une agence de l’eau, d’un département, d’un programme européen, etc.

Une évolution n’est pas l’entretien. Un abonnement consomme l’entretien, il ne le finance pas. L’entretien est un coût fixe, que couvrira la convention annuelle.

Et le choix des priorités ? Ceux qui financent le projet y trouveront une place. La façon dont elle s’organise se construit encore.

Pour votre informaticien

• Une évolution financée est spécifiée avant d’être estimée, puis livrée dans le même code, sous AGPLv3 : il n’existe pas de version à part pour celui qui l’a financée.
• Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Aucune évolution n’est encore en tour de table ni financée.
• La feuille de route ne dit pas encore combien de créneaux d’évolution restent en 2027.

La suite : La feuille de route

Comment ça marche

Aujourd’hui. Une seule personne développe et entretient l’observatoire : Mathias Broutin, de Mémoire du Vivant. Sa feuille de route est ouverte : chacun peut y lire les évolutions qui restent à financer, et en proposer d’autres.

Ce qu’un financement donne. Une voix, pas une propriété. Une structure qui finance est créditée, jamais propriétaire. Elle est nommée si elle le souhaite, et la somme qu’elle apporte reste confidentielle.

Financer une évolution. Chaque évolution est spécifiée et estimée en jours de travail : une structure sait exactement ce qu’elle finance, qu’elle la porte seule ou avec d’autres. Une fois livrée, l’évolution rejoint le code libre de tous. Toutes les installations en profitent, et chacun peut la faire évoluer à son tour.

Sans financer. Une évolution vous manque ? Proposez-la, même sans financement, en disant quel besoin elle sert, pour qui, et quelle structure la porterait. Utiliser l’observatoire et le citer, c’est déjà prendre place parmi ceux qui le font vivre.

Pour votre informaticien

Le code sera publié sous AGPLv3 en décembre 2026, dans un dépôt neuf, sans l’historique de développement.

Docs à paraître.

Ce que l’observatoire ne fait pas (encore)

• Aucune instance de décision n’est encore instituée.
• Aucun contributeur de code extérieur à ce jour.

Les évolutions ouvertes et leur mesure en jours : La feuille de route.