📝(metadata): Add publiccode.yml file

[camillem]

Purpose

Publiccode.yml is a meta-data standard recommended for Public Administration Open Source software projects. See https://yml.publiccode.tools/

Proposal

Hello @lebaudantoine , here is a first proposal, inspired by https://github.com/suitenumerique/docs/blob/main/publiccode.yml
Feel free to update it as you wish.
There is a web-based editor that helps updating such files: https://publiccode-editor.developers.italia.it/?countrySpecific=france

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add publiccode.yml project metadata file

⚙️ Configuration changes 📝 Documentation 🕐 Less than 10 minutes

AI Description

• Add a publiccode.yml file describing the project for public sector open-source catalogs.
• Document ownership, licensing, maintenance contacts, and supported platforms/languages.
• Provide localized product description and feature list for discoverability.

Diagram

graph TD
  A["GitHub repo"] --> B["publiccode.yml"] --> C{{"Publiccode tools"}}
  B --> D["Public sector catalogs"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Add CI validation for publiccode.yml

• ➕ Prevents schema regressions and malformed YAML
• ➕ Ensures required fields remain present over time
• ➖ Adds CI complexity and maintenance for the validator/versioning

2. Start with a minimal publiccode.yml and expand iteratively

• ➕ Lower initial content review burden
• ➕ Reduces risk of stale/incorrect claims in feature lists
• ➖ Less useful for immediate discovery and catalog ingestion

Recommendation: The PR’s approach (adding a complete initial publiccode.yml based on an existing template) is appropriate. Consider a follow-up to add automated validation in CI and/or periodic review to keep releaseDate, contacts, and feature claims current.

Files changed (1) +50 / -0

Other (1) +50 / -0

publiccode.ymlIntroduce publiccode.yml metadata descriptor +50/-0

Introduce publiccode.yml metadata descriptor

• Adds a publiccode.yml file following the publiccode standard, including project identity (name, suite, URL, release date), target platform/country, organization and funding info, licensing, maintenance contacts, and localization/language support. Includes an English localized description with a feature list to improve catalog discoverability.

publiccode.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Individual emails in contacts 🐞 Bug ⚙ Maintainability

Description

publiccode.yml lists maintenance contacts using individual email addresses, which makes the
published contact metadata likely to go stale when people change roles and can lead to
failed/undelivered support inquiries.

Code

publiccode.yml[R37-45]

+maintenance:
+  type: internal
+  contacts:
+    - name: "Samuel Paccoud"
+      email: samuel.paccoud@numerique.gouv.fr
+      affiliation: DINUM
+    - name: "Antoine Lebaud"
+      email: antoine.lebaud.ext@numerique.gouv.fr
+      affiliation: DINUM

Evidence

The metadata file publishes two individual email addresses under maintenance.contacts, while the
README points contributors/users to a stable role-based address (visio@numerique.gouv.fr) for
contact—suggesting a more durable contact channel exists.

publiccode.yml[37-45]
README.md[60-60]
README.md[164-168]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`maintenance.contacts` uses individual email addresses, which are more likely to become outdated over time.

## Issue Context
The repository already advertises a role-based contact address in documentation; using the same (or adding it as the primary maintenance contact) makes metadata more durable.

## Fix Focus Areas
- publiccode.yml[37-45]
- README.md[60-60]
- README.md[164-168]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Trailing spaces in descriptions 🐞 Bug ⚙ Maintainability

Description

description.en.shortDescription and description.en.longDescription include trailing spaces
inside quoted scalars, which become part of the published metadata value and can cause inconsistent
rendering or exact-string comparisons downstream.

Code

publiccode.yml[R22-25]

+    shortDescription: "Open Source video conference solution, based on LiveKit "
+    longDescription: "Open Source video conference application, based on LiveKit,
+      Django and React. It is the official web video conference application of
+      French Ministries. "

Evidence

Both shortDescription and longDescription visibly contain a space before the closing quote in
the added YAML, meaning the whitespace will be included in the parsed string value.

publiccode.yml[22-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The quoted description strings contain trailing spaces before the closing quote; YAML preserves these spaces as part of the scalar value.

## Issue Context
This is low impact but easy to fix and avoids publishing unintended whitespace in metadata.

## Fix Focus Areas
- publiccode.yml[22-25]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud