Face aux risques que fait peser GitHub sur le monde des logiciels libres suite à son rachat par Microsoft en 2018, une alternative semble avoir percé. Cette dépêche propose un tour d'horizon des problèmes posés par GitHub et expose comment Codeberg pourrait y répondre.

Sommaire

• • Les points forts de Codeberg
  • La problématique du tout GitHub
  • Des alternatives possibles
  • Pour vous faire venir sur Codeberg
    • Premières impressions
    • Fonctionnalités avancées
  • Projets ayant migré ou ayant un miroir sur Codeberg
  • Comment migrer vers Codeberg ?
  • Conclusion
  • Sources / Liens
    • Controverse GitHub
    • Forges diverses
    • Codeberg

Les points forts de Codeberg

L'association Codeberg e.V. ¹ et son projet Codeberg.org ont été fondés en janvier 2019, suite au rachat par Microsoft de GitHub. En plus d'un statut associatif à but non lucratif, ce qui limite les risques de disparition du jour au lendemain, Codeberg est basé en Europe (à Berlin), ce qui est un plus pour nos données personnelles.

Son logo représente un sommet enneigé sur fond de ciel bleu. En effet, en Allemand, der Berg veut dire la montagne et on pourrait donc traduire Codeberg par une « montagne de code ». Et effectivement, la communauté compte fin avril 2024 plus de 102 000 utilisateurs et plus de 129 000 projets y sont hébergés. L'association qui dirige le projet compte plus de 400 membres. Le financement s'effectue par les dons (déductible des impôts en Allemagne) et/ou contributions aux projets sous-jacents à la forge.

La forge est basée sur Forgejo, logiciel libre sous licence MIT, dont le nom vient de l'Esperanto forĝejo, ce qui est cohérent avec l'attention portée à la langue de l'utilisateur et aux problèmes de traduction (service Weblate). Comme avec GitLab, la licence libre implique qu'un projet peut posséder sa propre instance s'il le souhaite. On notera que Forgejo est un fork de Gitea, lui-même fork de Gogs, et est donc écrit en langage Go, langage sous licence BSD avec un brevet. Le projet Forgejo, évidemment hébergé sur Codeberg, est très actif avec plus de 900 Pull Requests acceptées depuis un an.

La problématique du tout GitHub

GitHub, lancé en 2008, est devenu la plus grosse plateforme d'hébergement de codes sources, utilisée par un grand nombre de projets majeurs du monde du libre (Firefox, Matrix, Yunohost…). Ce qui par effet d'attraction — et de réseau centralisant, contraire au choix de git décentralisé par nature — conduit souvent à faire de Github un choix par défaut, facilitant les interactions avec les autres projets et permettant d'accéder à une large base de contributeurs potentiels. Quand on cite une URL GitHub dans un réseau social, on peut d'ailleurs voir apparaître ce genre de message :

Contribute to Someone/my_project development by creating an account on GitHub.

Cependant, si ce service fourni par Microsoft est actuellement encore gratuit, il est soumis à son bon-vouloir, avec le risque de voir se répéter l'épisode SourceForge (publicités trompeuses, installateurs modifiés, usurpation d'identité de projets partis ailleurs, etc.).

Par ailleurs, derrière une communication favorable à l'open source, le code de la forge GitHub est volontairement fermé. Vous ne pouvez donc pas avoir votre propre instance de GitHub. En outre, cela laisse un flou sur l'exploitation de nos données (au sens large, le code lui-même et nos données personnelles, l'hébergement étant délégué). Avec l'arrivée du projet Copilot, il est cependant certain que nos codes servent à alimenter un outil d'IA, permettant à Microsoft de monétiser des suggestions de code en faisant fi des questions de licence. Une partie d'un code sous licence libre pourrait potentiellement se retrouver injectée dans un projet avec une licence incompatible et de surcroît sans citation de l'auteur.

Des alternatives possibles

On pense tout d'abord à GitLab, logiciel lancé en 2011, qui permet d'avoir sa propre instance serveur pour maîtriser l'ensemble (client et serveur sont libres). Parmi les grands projets libres, on trouve en particulier GNOME et Debian qui utilisent leur propre instance GitLab CE (Community Edition), logiciel sous licence MIT. Mais il faut nuancer : la forge GitLab.com utilise GitLab EE (Enterprise Edition) qui est propriétaire et propose des fonctionnalités supplémentaires. GitLab suit donc un modèle dit open core. GitLab compterait plus de 30 millions d'utilisateurs inscrits et l'entreprise GitLab Inc., lancée en 2014, génère plusieurs centaines de millions de dollars de revenus. On notera enfin qu'en 2018, le site migre de Microsoft Azure à Google Cloud Platform (USA), ce qui a posé des problèmes d'accès dans certains pays.

Autres projets de forges libres plus modestes :

• Codingteam.net (une initiative française, service clôturé en 2019).
• SourceHut http://sr.ht (et https://sourcehut.org/), initié par Drew DeVault.
• Disroot basé sur Forgejo comme Codeberg, mais il ne semble pas avoir attiré de projets d'envergure (le portail, sorte de Framasoft néerlandais, est néanmoins à recommander).
• Chez un Chaton (GitLab ou Gitea pour la plupart).
• L'auto-hébergement : chez-vous, dans un fablab, en datacenter sur serveur dédié…

Pour vous faire venir sur Codeberg

Premières impressions

La page principale est accueillante et annonce que Codeberg.org ne vous piste pas et n'utilise pas de cookies tiers. Les statistiques actuelles sont affichées : nombre de projets, d'utilisateurs et de membres de l'association. Chose agréable, vous avez la possibilité de choisir le français parmi les nombreuses langues proposées pour l'interface. Petite icône qui attire l'attention : l'activité de chaque dépôt peut être suivie grâce à un flux RSS. Sinon, l'organisation générale est très semblable à celle de GitHub ou GitLab et la prise en main de Codeberg se fait donc sans effort.

Fonctionnalités avancées

• Codeberg pages : permet de disposer d'un site web statique pour le projet
• Forgejo actions : pour dérouler automatiquement les actions nécessaires à l'intégration continue (CI/CD)
• Weblate : pour gérer les traductions de votre projet. On peut d'ailleurs y constater que parmi les traductions de Forgejo, le Français est dans le peloton de tête.

Projets ayant migré ou ayant un miroir sur Codeberg

Un certain nombre de projets importants utilisent désormais Codeberg, ce qui est à la fois un gage de confiance et assure une base de contributeurs a minima :

• libreboot : remplacement libre de BIOS/UEFI.
• Conversations : le client majeur XMPP sur Android.
• WideLands : jeu libre basé sur le concept de Settlers II.
• LibreWolf : fork de Firefox axé sur la vie privée.
• F-Droid : magasin d'applications libres pour Android.
• FreeBSD : miroir de https://cgit.freebsd.org/
• FreeCAD : miroir officiel.
• Forgejo : fork communautaire de Gitea suite à la privatisation de celui-ci en 2022.
• Fedilab : client Android pour le Fediverse.
• irssi : client IRC.
• Peppermint OS : une distribution Linux avec bureau minimaliste.
• DivestOS : un fork de LineageOS orienté sur la protection de la vie privée.
• VeggieKarte : un service pour trouver des restaurants végétariens/végétaliens.
• …

Comment migrer vers Codeberg ?

Migrer le code source et l'éventuel Wiki associé ne devrait pas poser de problème particulier. Il suffit de configurer git pour pusher vers la nouvelle forge. Cette page décrit comment migrer l'ensemble de votre projet (incluant les issues, le wiki, les Pull Request, etc.) vers Codeberg : https://docs.codeberg.org/advanced/migrating-repos/

Concernant les Workflows (CI), bien qu'il n'y ait pas de garantie de compatibilité avec les Actions Github, la syntaxe se veut similaire pour faciliter la transition : https://forgejo.org/2023-02-27-forgejo-actions/

Au-delà de l'aspect technique, il reste aussi à faire migrer la communauté d'utilisateurs (la présence fortement suivie sur Mastodon peut être un avantage).

Conclusion

Codeberg est un outil prometteur. Il reste pour la communauté du logiciel libre à le faire grandir. Rappelons les statistiques : 100 millions de développeurs sur GitHub, 30 millions utilisant GitLab et 100 000 pour Codeberg. Le potentiel est grand, l'un des enjeux est de financer l'association pour accompagner la croissance de la communauté, tout en faisant monter en puissance l'infrastructure informatique.

Sources / Liens

Controverse GitHub

• Sonnette d'alarme activée dès 2016 (fr).
• Pourquoi abandonner Github (en) : la campagne Give Up GitHub! a été lancée en juin 2022 suite à la controverse sur GitHub Copilot.
• Please don’t upload my code to GitHub (en) : résumé des problèmes posés en particulier par Copilot (IA GitHub).
• https://en.wikipedia.org/wiki/GitHub_Copilot#Licensing_controversy

Forges diverses

• https://en.wikipedia.org/wiki/GitLab
• Synthèse LinuxFR sur l'autohébergement (2018) (fr).

Codeberg

• Parcourir les projets hébergés sur Codeberg (en)
• Suivre Codeberg sur Mastodon (en) : 12000 abonnés.
• Le blog de Codeberg (en)
• Instances, projets et ressources autour de Forgejo (en)
• https://en.wikipedia.org/wiki/Codeberg

Cloonix est un outil d’aide à la construction de réseau virtuel. Il est basé sur Open vSwitch pour l’émulation du réseau constitué de switchs et LANs virtuels, sur crun et les namespaces pour la gestion de conteneurs et sur KVM pour ce qui concerne l’émulation des machines complètes.
Cloonix peut être considéré comme un hyperviseur qui permet de lancer des scénarios de démonstration impliquant des réseaux connectant de nombreuses machines virtuelles ou conteneurs. Ce logiciel open source permet d’automatiser et de rejouer des scénarios complets.

FRR est le logiciel open source qui permet de transformer une machine Linux en l’équivalent d’un routeur professionnel, ce logiciel implémente tous les protocoles de routage classique.

Podman est exactement comme Docker, un gestionnaire de conteneur.

Le but de cette dépêche est de présenter une démonstration qui tourne dans un podman et qui met en œuvre un réseau d’une soixantaine de conteneurs et qui peut être lancé en tant qu’utilisateur simple sans les droits root.

Il y a le lien « demo » qui montre une vidéo un peu accélérée de cette démonstration qui démarre les machines, les configure et les met en réseau. On peut ensuite y voir la convergence du protocole OSPF.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche.

Sommaire

• PixelOS
  • Installation
  • Interface
  • Fonctionnalités spécifiques/avancées de PixelOS
• GrapheneOS
  • Installation
  • Interface
  • Applications et « stores »
  • Gestion des autorisations
  • Séparation des usages
  • Détail des approches suivies
    • 1ʳᵉ approche
    • 2ᵉ approche (test en cours)
    • 3ᵉ approche (d’ici une semaine)
  • Détails : utilisation sans les services Google
    • Synchronisation des contacts & agendas
    • Quid des applications non libres hébergées sur le play store
  • Détails : Utilisation avec les services Google
    • Dans un profil séparé
    • Via la fonction « work profile » d’Android
• Conclusion, cas d’usages et « threat model » (modèle de menace)
  • Sécurité
  • Vie privée
  • Facilité d’utilisation
  • Note : l’impact du matériel (« hardware ») sur la vie privée

Le point de départ est celui d’un utilisateur sensible aux logiciels libres mais qui utilise un téléphone Android Samsung « comme tout le monde », avec :

• Utilisation du Google Play Store, avec un compte Google personnel
• Utilisation d’un compte Google professionnel
• Utilisation du Samsung store, avec un compte Samsung
• Utilisation d’une montre connectée Samsung avec appli Samsung health

L’utilisateur a déjà expérimenté par le passé les solutions suivantes :

• UbuntuOS (abandonné rapidement par manque d’applications)
• LineageOS, avec Micro-G + « signature spoofing » pour permettre l’installation des applications bancaires

PixelOS

Installation

La mise en œuvre du système « stock » installé sur le smartphone est très facile et simple d’utilisation. Les téléphones Pixel proposent des fonctionnalités « avancées » spécifiques qui sont proposées au démarrage, avec à chaque fois le jeu de « voulez-vous activer cette fonctionnalité ? Si oui, acceptez le contrôle des données suivantes… »
On est dans un environnement full google, donc avec quelques habitudes à changer me concernant venant d’un environnement Samsung (la surcouche de l’OS est différente).

Interface

Launcher Pixel avec une barre de recherche Google qui ne peut pas être enlevée (The search bar cannot be removed from the bottom of the home screen, it's part of the Pixel Launcher https://support.google.com/pixelphone/thread/133065648/is-there-any-way-to-remove-the-google-search-bar-from-the-home-screen?hl=en), sinon tout est fluide / "beau"

Fonctionnalités spécifiques/avancées de PixelOS

• Déblocage du téléphone par reconnaissance faciale (probablement un cauchemar en termes de privacy, mais je pourrais comprendre pourquoi une personne lambda souhaiterait activer ce service)
• « Double tap » au dos du téléphone pour lancer une action (dans mon cas : la lampe torche)
  • On peut utiliser Torchie pour une fonctionnalité proche (https://f-droid.org/fr/packages/in.blogspot.anselmbros.torchie/)
  • Les fonctions d’urgence « avancées » fournies par l’application « sécurité personnelle » (https://play.google.com/store/apps/details?id=com.google.android.apps.safetyhub&hl=fr&gl=US)
  • L’application est disponible sur le playstore mais ne fonctionne pas sur GrapheneOS
  • Il existe une fonction d’urgence « de base » dans GrapheneOS (AOSP ?) (appuyer 5x sur power pour lancer un appel d’urgence vers le 112)
  • Dans PixelOS, il y a un conflit de raccourcis entre « appuyer 5x sur power pour lancer un appel d’urgence » et l’option « appuyer 2x pour lancer l’appareil photo » (quand les deux sont activées : l’appareil photo prend le dessus)
• Paiements NFC (non accessibles sur GrapheneOS)
  • Certaines applications de paiement autres que Google Wallet peuvent fonctionner (par ex. Paylib)
• Fonctionnalité « bien être numérique », notamment le fait de passer l’écran en noir & blanc à partir d’une certaine heure pour tenter de limiter le temps devant les écrans. L’application existe dans le Play Store (https://play.google.com/store/apps/details?id=com.google.android.apps.wellbeing&hl=fr&gl=US) mais impossible à retrouver depuis le client Play Store sur le téléphone.
  • Il existe probablement des alternatives

GrapheneOS

Installation

Procédure d’installation web très simple et rassurante. C’est la première fois que je me verrai recommander ce type d’install à un utilisateur non technique (alors que la procédure d’install de LineageOS - à l’époque ou j’ai essayé - est complexe et obscure, avec le risque de se planter à plusieurs étapes).

Interface

• Le bureau par défaut est très minimaliste et pas très accueillant (je sais que cela peut paraître peu important, mais le fond noir + icônes en noir & blanc peut rebuter / n’est pas aussi accueillant que le système de base).
  • Possibilité d’utiliser un launcher alternatif : j’ai fini sur Lawnchair après en avoir testé plusieurs
  • Possibilité de changer le fond d’écran : Muzei (https://f-droid.org/fr/packages/net.nurik.roman.muzei/) / Walman (https://apt.izzysoft.de/fdroid/index/apk/com.colorata.wallman)
• Le clavier par défaut m’a dérangé (après des années à utiliser le clavier Gboard), surtout pour l’écriture « swipe » (que je pratique souvent quand j’écris un message à une main).
  • Possibilité d’utiliser un clavier alternatif : Home:FlorisBoard (https://f-droid.org/fr/packages/dev.patrickgold.florisboard/) est pas mal, il inclut une fonction « swipe » mais qui n’est pas aussi précise

Applications et « stores »

• Le « store » par défaut « Apps » contient le minimum vital.
  • Pour le compléter, je suis passé par l’application Droid-Ify (https://droidify.eu.org/ ou https://github.com/Droid-ify/client) dans lequel j’ai activé les dépôts F-droid et Home:IzzyOnDroid

Pour le Store Google, il est possible d’installer plusieurs « briques » de l’éco-système :

• Google Services Framework (GSF), dont dépendent :
  • Google Play services + Google Play Store (interdépendants) On peut donc choisir : rien du tout, GSF pour les applis qui en dépendent, ou les trois.

Gestion des autorisations

• Les possibilités sont très fournies = positif (permet de limiter les accès réseau, les accès stockage)
• Les possibilités sont très fournies = complexe à gérer : il faut se poser des questions / passer du temps à configurer les choses.
  • Exemple : la synchronisation des contacts Google ne se fait pas sans la permission « Contacts » dans l’appli « Google Services Framework ».

Séparation des usages

Il existe deux approches possibles de séparation des usages :

• Utilisation d’un « user profile » : il s’agit d’un profil complètement distinct. On peut passer de l’un à l’autre assez facilement. Les deux profils ne peuvent pas se parler, sauf via les notifications croisées (https://www.youtube.com/watch?v=WjrANjvrSzw)
• Utilisation d’un « work profile » : ici on utilise un seul profil, mais à l’intérieur duquel on vient activer la fonctionnalité « work profile » d’Android pour séparer les usages (via une application tierce telle que Shelter, https://www.youtube.com/watch?v=20C0FD7mGDY pour une explication détaillée)

Détail des approches suivies

1ʳᵉ approche

• Profil « owner » avec Shelter
  • Profil « Personnel » = pas de services Google
  • Profil « Professionnel » = Services Google avec compte personnel
• 2ᵉ Profil « Travail » = Services Google avec compte professionnel

Ce qui bloque : je voulais utiliser la fonctionnalité « work profile » d’Android avec Shelter pour isoler mon compte Google personnel. Hors c’est ce compte qui jusqu’ici synchronise les contacts. Les applications par défaut de GrapheneOS ne gèrent pas cette synchro (autrement que via import/export manuel, ou alors je n’ai pas trouvé comment). Si on veut quelque chose qui s’intègre tout seul il faut passer par les applications Google de Téléphone/Contacts/Calendrier. Hors ces applications ne peuvent pas devenir « applications par défaut » (pour remplacer celles existantes de GrapheneOS) dans le « work profile », c’est le profil personnel qui gère cette configuration.

2ᵉ approche (test en cours)

• Profil « owner » (unique, sans Shelter) = Services Google avec compte personnel
• 2ᵉ Profil « Travail » (unique, sans Shelter) = Services Google avec compte professionnel

Ce qui bloque : j’utilise le téléphone à la fois pour le pro & perso, sauf que le fait d’avoir deux profils implique de jongler systématiquement entre les deux profils. Trop compliqué au quotidien.

3ᵉ approche (d’ici une semaine)

• Profil « owner » avec Shelter
  • Profil « standard » = Services Google avec compte personnel
  • Profil « work » = Services Google avec compte personnel

Détails : utilisation sans les services Google

Synchronisation des contacts & agendas

La première problématique c’est la synchro des contacts et des agendas. Pour se passer de Google sur ce point, il faut mettre en place au préalable un service de partage de contact / agenda :

• Nextcloud + DAVx⁵
• https://www.etesync.com/
• https://www.chatons.org/
• NAS Synology + leurs applications (mais uniquement accessibles sur Google Play Store…)

Bref c’est un projet en tant que tel, pas forcément à la portée de tous

Quid des applications non libres hébergées sur le play store

À ce stade, pour accéder à d’éventuelles applications uniquement présentes sur le Play Store, il est possible de :

• passer par l’application Aurora
• passer par apkmirror pour les télécharger une à une

Cependant, de nombreuses applications du Play Store requièrent l’installation du Google Services Framework (« GSF ») pour fonctionner.

Me concernant, j’ai la liste suivante d’applications que j’ai pu récupérer par ce biais (et qui fonctionnent sans GSF) :

• Appli Banque (SG)
• Paiement NFC via Paylib (pas encore testé « en vrai » mais l’appli s’installe sans broncher)
• Deezer (musique)
• Somfy (alarme)
• NetAtmo (thermostat connecté)
• Doctolib (Santé)
• Appli mutuelle (Alan)
• Freebox connect (utilitaire freebox)
• Wifiman (utilitaire réseau)

Certaines applications nécessitent le GSF, c’est le cas notamment de :

• Whatsapp (pour les notifications « push » et pour transfèrer l’historique des messages)
  • Il semble que des transferts « locaux » soient possibles
    • https://faq.whatsapp.com/6181521285295518/?helpref=hc_fnav&cms_platform=android
    • https://faq.whatsapp.com/209942271778103/?helpref=hc_fnav&cms_platform=android
• Bose connect (gestion casque bluetooth Bose qui indique l’erreur « Services Google Play manquants »)
  • Le casque peut fonctionner en bluetooth sans l’application

Détails : Utilisation avec les services Google

Dans un profil séparé

J’ai mis du temps à comprendre / trouver comment activer la fonctionnalité de profils multiples (alors que c’est simple) : Paramètres > Système > Utilisateurs multiples > Autoriser plusieurs utilisateurs (https://www.youtube.com/watch?v=SZ0PKtiXTSs)

Le profil séparé à l’avantage d’être comme un « deuxième téléphone ». C’est aussi un inconvénient pour les personnes qui ne sont pas prêtes à faire cet « effort » (passer de l’un à l’autre), même si les notifications « cross profile » aident sur ce point.
Il faut reproduire sur chacun des profils toutes les « custo » faites (changement de launcher, de clavier, configurations diverses, etc).

Via la fonction « work profile » d’Android

La fonction work profile fournit une séparation moins forte, mais c’est aussi plus « pratique » au quotidien car toutes les applications (et les comptes) sont dans un seul profil. J’ai testé via l’application Shelter.

Avantages :

• Tout est accessible dans le même profil
• Dans le tiroir d’application, on retrouve deux « onglets » séparant les applications « perso » et « pro ».

Inconvénients :

• Comme pour le profil séparé, il y a une « double maintenance »
  • Ex: en cas d’utilisation de deux profils Google Play (profil perso + pro), il faut faire les mises à jour « des deux côtés »
• Il faut bien choisir dans quel contexte on souhaite installer chaque application
• Je n’ai pas trouvé comment faire pour 1. Synchroniser mon compte Google perso dans le « work profile » de Shelter et 2. faire remonter ces informations dans les applications « contacts » et « téléphone » par défaut de GrapheneOS. C’est le profil « Personnel » qui va dicter quelles applications par défaut sont utilisées.

Conclusion, cas d’usages et « threat model » (modèle de menace)

J’ai passé beaucoup plus de temps que prévu à comprendre GrapheneOS, tester différentes solutions et configurer les options / trouver des alternatives. Je suis bien conscient que plusieurs « problèmes » remontés pourraient tout simplement être résolus si j’acceptais de faire les choses différemment. Cela me pousse à m’interroger sur le compromis à choisir entre sécurité / respect de la vie privée / facilité d’utilisation ? Cette question dépend bien sur du modèle de menace (« threat model ») de chacun.

Sécurité

GrapheneOS répondrait parfaitement à des contraintes de sécurité « forte » pour des personnes étant journaliste / activiste / lanceur d’alerte / député. Dans ce cas d’usage, le coût de la sécurité est accepté.

Vie privée

GrapheneOS apporte un choix indéniable permettant à chacun de trouver le meilleur usage possible.

Facilité d’utilisation

Dans mon cas d’usage, je trouve que la fonction de profil séparé apporte trop de friction au quotidien, et je suis prêt à tout rassembler au sein du même profil. L’utilisation de deux téléphones différents (un perso / un pro) pourrait être une alternative. De la même manière, je n’ai pas encore passé le pas de me séparer de mon compte Google (pour la synchro des contacts / agendas), donc pour le moment je continue d’utiliser le Play Store. À terme, j’essaierai de ne plus en dépendre.

Note : l’impact du matériel (« hardware ») sur la vie privée

• Un casque Bluetooth Bose nécessite l’app « Bose Connect » qui dépend de GSF/Play Store
• Un casque Bluetooth Samsung Buds2 Pro nécessite l’app Samsung qui demande la création d’un compte cloud chez eux
• L’application Google Wallet me permet de régler mes courses via paiement NFC, mais donne accès par ce biais à un pan entier de données personnelles

À chaque fois la question est : est-ce utile ou pas ? Puis-je facilement m’en passer ?

Récit de mon aventure en tant que contributeur pour le projet Open Food Facts, la base de donnée alimentaire ouverte et collaborative, où je suis arrivé un peu par hasard en 2015.

Depuis son lancement par Stéphane Gigandet en 2012, le projet a beaucoup évolué et les contributions ont augmenté de façon exponentielle. D’abord centré sur des données de produits vendus en France, la base compte désormais 3 100 000 produits et 18 pays ayant dépassé les 10 000 produits référencés.

L’impact de ces données a pu se voir à travers le Nutriscore qui a pu être testé sur un grand nombre de produits grâce à Open Food Facts. Désormais, plusieurs projets avancent de front et en partenariat avec d’autres acteurs, notamment autour de l’empreinte carbone (EcoScore), des emballages (avec l’ADEME) ou de la surveillance de la réduflation (avec l’ONG Food Watch).

Sommaire

• • Découverte & premiers pas
  • Contribution(s)
  • Changements notables
  • Limites
  • Perspectives
  • Conclusion
  • Liens & ressources

Découverte & premiers pas

Je raconte souvent que j’ai découvert Open Food Facts (OFF) grâce à José Bové. Pas directement, certes, mais il a joué un grand rôle dans mon intérêt pour OFF.

José Bové n’est pas content contre le dioxyde de titane (E171)

Mars 2015 : je regarde d’un œil torve BFM TV et je vois un José Bové énervé contre un additif : le E171 (aussi connu sous le nom « dioxyde de titane »). Face à Jean-Jacques Bourdin, il sort des paquets de M&M’s et de chewing-gum, cite les marques et incite les téléspectateurs à boycotter ces produits qui contiennent ce colorant controversé.

Pas forcément renseigné sur les enjeux autour de ce colorant, j’ouvre la page Wikipédia de celui-ci. Je lis en diagonale ce qui est marqué et, en bas, je vois un lien où il est indiqué « Liste des produits contenant du E171 sur Open Food Facts ».

Je découvre l’interface moche (signe de reconnaissance des projets portés par des bénévoles et où l’aspect visuel est souvent en bas de la liste des priorités) de OFF et comprend très vite les grandes lignes du projet : un Wikipédia des aliments qui se base sur les informations présentes sur les emballages. Ni plus, ni moins.

En découvrant OFF, je suis étonné que le projet n’a été lancé qu’en 2012. Naïvement, je pensais que les données alimentaires étaient obligatoirement partagées par les producteurs et centralisées quelque part, à des fins de contrôle de conformité par exemple. Mais finalement non : les rares bases de données qui existent ne sont pas ouvertes.

Quand j’arrive sur le site, le projet vient de dépasser les 30 000 produits dont 90% sont français. À l’époque, je ne suis pas libriste (je crois que je ne connaissais pas la différence entre logiciel libre et logiciel propriétaire), je ne contribue à aucun commun numérique et, ironiquement, je ne suis pas très intéressé par les questions autour de l’alimentation.

Contribution(s)

Rapidement, je ne sais plus où donner de la tête : il y a tant de choses à faire pour aider !

Au début, j’aide à compléter les fiches. On parle d’une époque où il n’y a aucun outil de reconnaissance de caractères intégré au projet donc, la liste d’ingrédients, il faut forcément la remplir à la main. Plutôt simple pour un jus de fruit, beaucoup moins pour un gâteau industriel.

Comparaison de deux listes d’ingrédients : l’une avec beaucoup d’ingrédients et l’autre avec peu

L’ajout de nouveaux produits est rapidement un réflexe que de nombreux contributeurs et contributrices de OFF ont connu : en revenant des courses, je me retrouve à genoux sur le sol de ma cuisine pour prendre les meilleures photos possibles d’une conserve de haricots ou d’une galette complète surgelée. Je suis moins fan de prendre des photos directement en rayon : on parle d’une époque pré-Yuka où scanner un produit n’est pas du tout dans les habitudes du consommateur moyen (et encore moins le prendre en photo). Autre réflexe : ramasser parfois des déchets dans la rue pour voir si — au cas où — ils ne sont pas dans Open Food Facts (et les mettre dans la poubelle jaune en passant, tout de même :D ).

La question des catégories — et surtout de la taxonomie de celles-ci — devient rapidement un point central de mes contributions : pour comparer des produits d’une même catégorie, encore faut-il que ceux-ci en aient une. La complétion des autres champs, bien qu’importante, me paraît secondaire sur la mission de classer les produits le plus finement possible.

Un autre sujet qui m’intéresse : les estampilles sanitaires. Ces codes qui sont obligatoires sur certains produits (notamment ceux issus d’animaux) permettent de connaître le lieu de préparation de ceux-ci. Multipliez les fiches avec ces codes, couplez-les avec la liste, publique, des sites de productions correspondant et vous obtenez la carte « C’est fabriqué près de chez-moi ». Avec cette carte, on a rapidement « repéré » certains sites majeurs, comme l’usine d’Aucy, à Theix (près de Vannes), qui a rapidement dépassé les 300 références.

Carte des sites de production centrée sur le Golfe du Morbihan

Changements notables

Le grand changement qui a révolutionné la contribution à OFF, ce sont les modifications semi-automatisées permises par Hunger Games. Rajouter, en quelques minutes, la marque de centaines de produits accélère considérablement la contribution et permet d’avoir une base de donnée toujours plus complète. À terme, ce projet a sûrement vocation à devenir la Street Complete de Open Food Facts (en tout cas, je l’espère :D ).

Depuis fin 2022, nous avons enfin réussi à infléchir la courbe des produits sans catégorie (qui ne faisait que monter depuis 2017)

Pour ce qui est de l’ajout de nouveaux produits, il y a clairement eu un avant et un après Yuka. Cette application se basait, à ses débuts en 2017, sur OFF. Elle a depuis créé sa propre base mais rebascule les photos et certaines données sur OFF. Bien que l’ajout de nouveaux produits ait tendance à se diversifier avec le temps (via l’arrivée d’applications similaire dans d’autres pays notamment), Yuka a clairement donné un coup d’accélérateur incroyable à OFF : à l’heure où j’écris ces lignes, près de 60% des produits ont été ajoutés via cette application. Même si de nombreuses données sont ajoutées sur OFF par la suite sur ces produits, cet apport est essentiel pour la croissance de la base.

Liste des principaux contributeurs qui sont des applications pour les 15 plus importants (« kiliweb » est l’identifiant de l’application Yuka dans OFF)

Des projets annexes ont vu le jour : Open Beauty Facts, Open Pet Food Facts et Open Products Facts. Ces trois projets, à chaque fois lancés sous forme de blague le 1ᵉʳ avril, sont devenus des projets sérieux qui avancent à leur rythme dans le sillage de OFF. Le projet de fusionner tous ces projets est en gestation depuis plusieurs années, mais devrait se concrétiser bientôt.

La refonte graphique du projet actée pour les 10 ans de OFF a été très bien mise en place. La nouvelle page d’accueil est plus agréable, le logo est super et, surtout, les fiches produits sont très bien organisées. Il y a également une cohérence graphique entre le site web et l’application smartphone.

Ancien logo vs. nouveau logo

Dernière chose qui démontre la maturité du projet : la mise en place d’un groupe de travail dédié à la qualité des données. Depuis sa mise en place, de nombreuses erreurs de valeurs nutritionnelles ont été corrigées en priorisant les produits les plus scannés via près de 200 contrôles (ex : il y a un problème si un produit est noté avec « 120 g de sucre pour 100 g »). Ce travail va désormais porter sur la qualité des ingrédients renseignés et, là, on passe à un autre niveau de complexité…

Un mème que j’avais bricolé il y a quelques mois et qui illustre le chantier qui nous attend pour améliorer la qualité des ingrédients.

Limites

Selon moi, le gros point noir de OFF est son application smartphone. Celle-ci rend la contribution laborieuse. À tel point que j’ai tendance à rester sur PC, même pour l’envoi de photos. Aussi, le décalage entre les versions disponibles sur Google Play/App Store d’un côté et F-Droid de l’autre est dommage.

Une autre limite est, selon moi, le lien que l’on a, en tant que contributeur, aux données que l’on ajoute.

Je m’explique : j’ai un peu contribué à OpenStreetMap (projet que j’ai découvert via mon implication à OFF, en passant). J’ai fait des modifications assez modestes, mais j’ai un lien assez fort aux données que j’ai ajoutées. Mais j’ai souvent en tête ces contributions et le fait qu’elles sont utiles à de nombreuses ré-utilisations via des applications tierces. Constater ces ré-utilisations crée une sorte de fierté d’avoir contribué à ce projet. Et une incitation à continuer. Christian Quest en a d’ailleurs parlé lors des derniers « OFF Days », en décembre 2023.

Cette incitation est assez faible dans le cas de OFF. Personnellement, ce qui me pousse et m’a toujours poussé à contribuer est de voir passer des articles scientifiques qui utilisent OFF comme source de données principale, notamment autour du Nutriscore.

D’ailleurs, lors des dix ans d’OFF, le docteur Chantal Julia a évoqué le travail l’équipe du Pr Serge Hercberg (l’inventeur du Nutriscore) et est venue parler de l’impact d’OFF dans l’élaboration de cet indicateur. Elle a prononcé la phrase : « Le Nutriscore n’en serait pas là aujourd’hui si Open Food Facts n’existait pas ». Cette phrase résume la raison de mon implication dans ce projet.

Intervention du Dr Chantal Julia pour les Open Food Facts Days 2022

Autre étonnement : la dépendance du projet à des outils non libres. Le fait que tout s’organise sur Slack, par exemple, est dommage et l’utilisation de services Google l’est également. Loin de moi l’idée de passer pour un puriste (on a tous nos contradictions à ce sujet) mais lorsque des alternatives existent, cela devrait être un réflexe pour tout projet de les utiliser en priorité. Je pense notamment aux outils portés par l’association Framasoft.

Le contrôle des produits ajoutés serait à renforcer : OFF déborde de produits dont le code-barre est erroné. Cela peut être intentionnel (vandalisme de données) ou non (erreur du lecteur de code-barre ou faute de frappe). La conséquence : un travail de fourmi pour transférer les photos au bon produit puis supprimer la mauvaise fiche. Heureusement, pour les produits qui n’ont ni photo ni données, la procédure est souvent automatisée et, passé un certain délai, la fiche est supprimée. La conséquence : une partie non négligeable des produits ajoutés sur OFF sont destinés à être supprimés à long terme. De ce que j’ai pu en constater, j’estime que cela représente entre 10 et 15% des produits ajoutés sur une année (chiffre à prendre avec des pincettes).

Comparaison des produits ajoutés par année entre le 2 janvier 2023 et le 10 février 2024. Entre ces deux dates, plus de 77 000 produits ont été supprimés car erronés.

Dernier regret qui, j’imagine, est partagé par le reste des bénévoles : n’avoir jamais pu développer de communautés locales de contributeurs. Je pense que c’est dû à la nature des données : il est plus facile de créer un groupe local lorsque celles-ci sont liées à l’endroit où l’on réside (comme pour OpenStreetMap par exemple). Quelques « scan party » ont été organisées ici ou là, mais je n’ai pas le sentiment que ça ait initié quelque chose de concret.

Enfin, je veux terminer cette partie en clarifiant un point : j’adore OFF et j’ai prévu de continuer à y apporter ma pierre à l’avenir. Cette section a uniquement pour but de souligner quelques-unes des pistes d’amélioration.

Perspectives

Les projets lancés récemment autour des emballages, en partenariat avec l’ADEME, me paraît très intéressant. Même si je suis terrifié par la montagne de travail que représentent ces contributions, qui demandent de peser chaque élément de l’emballage avec une balance de précision, prendre la photo de celle-ci, l’envoyer sur la fiche et renseigner toutes les informations.

Opération Plein pot sur les emballages en partenariat avec l’ADEME

Un autre projet plus récent : OpenPrices. L’ambition est de suivre les prix des produits. Sacré boulot en perspective vu la volatibilité de cette donnée. Reste que les premiers résultats valent le détour et des processus ont déjà été élaborés pour automatiser certaines contributions.

Interface du projet Open Prices

La taxonomie des ingrédients est également prometteuse. Un peu de la même manière que les catégories (quoique plus complexe), référencer les ingrédients dans une arborescence (potentiellement liée aux données de Wikidata) va permettre de nouvelles réutilisations. Il y a également le projet de réaliser une taxonomie des marques.

Conclusion

À travers Open Food Facts, j’ai mis un pied plus globalement dans le monde du libre. Parfois, la motivation baisse devant l’aspect "sisyphéen" du projet : pour une fiche correctement complétée, 100 produits sont ajoutés. Mais, voir l’impact concret de son travail, par exemple via le Nutriscore, est très gratifiant.

Entre mon arrivée et aujourd’hui, la taille de la base mondiale a été multipliée par 100 et le taux de produits français a largement diminué, preuve de l’internationalisation du projet. Même si beaucoup reste à faire, OFF a d’ores et déjà apporté sa pierre à la transparence alimentaire.

Si j’ai incité ne serait-ce que deux ou trois personnes à modifier une fiche ou à ajouter un produit, j’aurai atteint mon objectif. Mais plus que Open Food Facts, cet article a pour but de vous inciter à contribuer à un commun numérique. Je tire surtout de cette expérience des rencontres et des discussions enrichissantes avec l’équipe au cœur du projet.

Photo de groupe aux OFF Days 2023

P.S. : Le E171 (ou dioxyde de titane), ce colorant controversé par lequel je me suis intéressé à OFF, est désormais interdit en Europe depuis 2022 après que la France l’ait bannie des aliments l’année précédente.

José Bové doit être content. :)

Liens & ressources

À lire
Mange et tais-toi (Serge HERCBERG, Editions humenSciences, février 2022)

À voir
Présentation d’Open Food Facts à l’édition 2015 de la convention Pas Sage en Seine
Une vidéo de la chaîne Projet Utopia qui parle surtout de Yuka mais aussi (un peu) de OFF

À écouter
Manon Corneille de Open Food Facts sur le podcast Projet Libres
Un épisode de l'émission "Le Meilleur des Mondes", sur France Culture, qui aborde les applications comme Yuka et Open Food Facts

Il y a 10 mois, je vous annonçais dans une dépêche la naissance de la version Beta de Scribouilli. Scribouilli a pour but d’être une solution simple pour réaliser un blog ou un petit site internet de quelques pages utilisable avec des personnes sans grande connaissance informatique.

Depuis lors, on a pu voir sur les réseaux l’annonce d’une version 1.0 pleine d’améliorations par rapport à ce que je vous avais présenté. Pour faire court, toutes les limitations de la version Beta que j’avais pointées dans la dépêche précédente ont été levées.

Sommaire

• Hébergement
• Blog
• Ergonomie
• Modifier l’apparence du site
  • Page d’accueil
  • La page Articles
  • Alignement des images
  • D’autres exemples
  • Réflexions concernant le CSS
• Aider
• Conclusion

Hébergement

Dans sa première version, Scribouilli nécessitait d’avoir un compte GitHub et cela n’est pas du genre à plaire à tout le monde. Désormais, lorsque vous vous lancez avec Scribouilli, vous tombez rapidement sur cet écran :

Il s’agissait d’une évolution qui était envisagée depuis le départ ou quasiment. L’arrivée relativement rapide de cette évolution a clairement été aidée par le fait que Framasoft a choisi d’utiliser Scribouilli pour les mini-sites dans le cadre de la refonte de framalibre.org. L’usage de GitHub par Scribouilli n’était pas trop au goût de Framasoft. Si vous l’ignorez, Microsoft a racheté GitHub en 2018 et même si GitHub est devenu une référence pour trouver les projets open source, GitHub.com lui-même n’est pas open source.

Le caractère non-opensource de GitHub est une des raisons de ne pas être fan d’un outil qui passe par GitHub mais GitHub est aussi un monde intimidant pour une personne lambda sans background spécifique en informatique. Dans la première version de Scribouilli, il fallait aller sauvegarder les images du site dans GitHub et puis revenir à Scribouilli pour insérer l’image avec le code markdown adéquat. Désormais, un lien permet d’uploader les images à partir de Scribouilli qui par ailleurs génère le code markdown qui va bien. Il reste donc à copier ce code et le coller à l’endroit adéquat de la page ou article en rédaction. Il n’est donc plus nécessaire de quitter l’interface de Scribouilli.

L’évolution de l’interface de Scribouilli apporte deux autres améliorations en lien plus ou moins direct avec l’hébergement. Premièrement, dans ses premières versions, le parcours supposait systématiquement que l’on voulait créer un nouveau site. Pour modifier un site, il fallait faire comme si on allait créer un nouveau site et puis cela se passait bien. Désormais, on a explicitement le choix entre créer un nouveau site ou en modifier un existant. La seconde évolution est que pour un même compte GitLab, GitHub ou ScribouGit, il est maintenant possible d’avoir plusieurs sites internet.

Dernier point en lien avec l’hébergement, l’URL qui était générée dans la version Beta était assez particulière et surtout peu parlante. Désormais, lors de la création d’un nouveau mini-site ou blog, on choisit le nom de celui-ci et l’URL prend la forme : adresse du dépôt / nom du site. Si l’on souhaite un nom de site encore plus sur mesure, il y a moyen avec quelques incantations plus ou moins magiques de lier un nom de domaine personnel à son site.

Blog

Dans la dépêche précédente, j’écrivais

Autant Scribouilli me paraît parfaitement utilisable en l’état pour un site simple de quelques pages, autant son utilisation pour un blog me paraît moins évidente. En effet, le menu deviendra vite illisible si l’on crée une page pour chaque nouveau billet.

En parlant du menu, remarquons qu’il n’y a pas vraiment moyen de choisir l’ordre dans lequel les pages apparaissent dans le menu. Il me semble que les pages sont classées par ordre alphabétique avec une exception pour la page accueil qui, indépendamment de son nom, apparaît de manière assez logique en première.

L’absence de création d’un flux RSS est aussi une caractéristique peu gênante pour un site de quelques pages mais qui peut être plus ennuyante dans le cadre d’un blog.

Et bien aujourd’hui, Scribouilli ne possède plus ces limitations. Dans les paramètres, on peut demander l’ajout d’une page Articles.

Comme vous pourrez le voir un peu plus bas dans cette dépêche, la page Article sert comme page menu de tous vos posts de blog qui apparaissent dans l’ordre chronologique de création.

Pour ce qui est du menu général du site qui apparaît à droite dans le bandeau du haut, il y a désormais moyen de modifier l’ordre d’apparition des différentes pages. Une petite exception concerne la page Articles qui apparaît toujours en première dans le menu.

Finalement, associé à la page Articles, un flux RSS est également généré.

Ergonomie

Deux autres évolutions positives que je classifie dans ergonomie concernent la prévisualisation des articles et la possibilité de consulter le code markdown des pages sans devoir relancer tout le cycle de la publication.

Dans la version Beta, même si on n’avait rien changé à une page dont on venait de vérifier le code, il fallait lancer un cycle complet de publication du site. Aujourd’hui, ce n’est plus le cas.

La prévisualisation est déroutante pour une personne habituée à écrire pour Linuxfr.org vu que la prévisualisation se déroule en temps réel, il n’est nul besoin de demander une prévisualisation en actionnant un quelconque bouton. La prévisualisation est toujours disponible et visible quand on tape le markdown.

Modifier l’apparence du site

Dans la dépêche précédente, je notais que le look était à prendre ou à laisser. La vitesse de développement de Scribouilli m’amenait à me contredire rapidement dans les commentaires. En effet, une possibilité de modifier le code CSS avait été ajoutée à Scribouilli.

Je terminais mon commentaire en indiquant que je n’avais plus qu’à apprendre le CSS. LinuxFR n’étant pas à une sournoiserie près, j’étais désigné dans les primés de mars 2023 des meilleures contributions. Je me suis senti obligé de prendre un livre qui se révélera excellent sur le CSS. LinuxFR récidivant quelques mois plus tard, je me sentais de nouveau obligé de choisir un livre en lien avec les sites internet et le CSS (qui s’avérera tout aussi intéressant). Première morale à cette histoire, contribuez à LinuxFR, vous n’êtes jamais à l’abri de recevoir l’opportunité de compléter votre bibliothèque.

Seconde morale à mon histoire, je me sens invité à vous partager quelques adaptations que j’ai faites à mon blog à l’aide du CSS. Vous ne perdrez pas de vue que ma connaissance du CSS reste très récente et relativement limitée. Par ailleurs, étant de base plutôt satisfait du look de Scribouilli, ne vous attendez pas à des modifications radicales. Ces exemples permettront de donner une idée du genre de chose possible à réaliser ainsi que d’illustrer certaines limites de la démarche.

Page d’accueil

Commençons par la page d’accueil. L’image ci-dessous présente à gauche mon blog avec mes adaptations et à droite son look avant transformation.

En haut à gauche, on remarque que j’ai ajouté une sorte de logo à mon blog. Les quelques lignes de CSS qui permettent cela :

header div.container {
  background-image: url(https://github.com/t-isaac/test-website-repo-3796/raw/main/images/logo.avif);
  background-repeat: no-repeat;
  background-position: left center;
  background-size: contain;
}

Lignes que j’ai dû compléter afin de gérer plus ou moins correctement l’affichage sur des petits écrans (tablettes, ordiphone,…) par une série d’instructions du type:

@media only screen and (max-width:430px) {
  header div.container{
      background-size: 40%; }
}

Les personnes les plus attentives auront remarqué que contrairement à ce que j’ai écrit plus haut dans cet article, j’ai réussi à modifier l’ordre d’apparition dans le menu en haut à droite de la page Articles. C’est une petite astuce permise avec le CSS, il suffit de demander d’afficher ce menu dans le sens inverse (de gauche à droite plutôt que de droite à gauche). J’en profite aussi pour légèrement réduire l’écartement entre les deux éléments du menu.

header ul {
  flex-direction: row-reverse;
  gap: 0.45rem;
}

Ce petit truc a ses limites. Par exemple, il ne fonctionnera pas si vous souhaitez avoir une section contact et que les pages apparaissent dans l’ordre suivant : Accueil – Articles – Contact. Systématiquement, la page Articles devra apparaître soit en premier, soit en dernier.

Jusqu’à présent, nous avons parlé du bandeau supérieur qui en fait n’est pas spécifique à la page d’accueil et que l’on retrouvera également sur toutes les autres pages. Le bateau est par contre un élément spécifique de la page d’accueil. Il s’agit d’une image svg. Au niveau du CSS, il faut gérer deux éléments : la couleur pour que le bateau soit toujours de la même couleur que le reste du site et l’alignement de l’image qui par défaut apparaîtrait au-dessus du texte de la page d’accueil.

svg {
   fill: var(--couleur-primaire);
   stroke: var(--couleur-primaire);
}

#Voilier {
   float: left;
   margin-left: 0rem;
}    

Vous pouvez aller vérifier, depuis les captures d'écran, j’ai changé la couleur de mon site et le voilier a suivi le mouvement.

La page Articles

Continuons par la page Articles. De nouveau, l’image ci-dessous présente à gauche mon blog avec mes adaptations et à droite son look avant transformation.

L’apparition du flux RSS n’a rien à voir avec mes transformations mais est liée au fait que l’image de droite a été prise avant l’introduction de cet élément dans Scribouilli.

Je ne suis pas trop fan de la présentation par défaut de Scribouilli. J’ai donc fait pas mal de modifications ici. D’autant plus que j’y ai ajouté quelques modifications pour le fun d’essayer certaines des fonctionnalités du CSS. Reconnaissons que le point négatif de mes modifications est sans doute une moindre lisibilité.

La première chose que j’ai faite, c’est de supprimer les Lire l’article et les lignes de séparation:

hr, article.blog-item > a {
  display: none;
}

Ensuite, je diminue la taille des titres, je les souligne et je prévois une transition pour quand on les survole:

.blog-item h2 a {
  font-size: 1.25rem;
  text-decoration: underline;
  transition: 0.1s;
}

Je réduis drastiquement l’espace entre les différents titres de post:

.blog-item, .blog-item h2 {
  margin-top: 0rem;
  margin-bottom: 0rem;
}

Ce n’est pas hyper utile et cela donne des trucs bizarres avec les écrans tactiles, mais j’agrandis les titres quand on les survole avec la souris:

.blog-item h2 a:hover {
  font-size: 1.5rem;
}

Je termine mes modifications en prévoyant un changement de couleur quand le lien a été visité:

.blog-item h2 a:visited {
  color: silver;
}

Alignement des images

Le dernier type de modification que j’ai apporté concerne l’alignement des images. Ci-dessous, de nouveau à gauche le blog après mes modifications et à droite, le même blog mais sans modification du code CSS de Scribouilli. Par défaut, les images sont alignées sur la gauche et il n’y a aucun texte autour de l’image.

En quelque sorte, j’ai dû tricher. En effet, en se limitant juste au CSS, il n’est pas vraiment possible d’obtenir des alignements différents pour les différentes images. Pour y arriver, je dois introduire mes images non pas avec du markdown mais avec du code HTML. Je définis différentes classes qui sont gérées par du code spécifique dans mon CSS. Par exemple, j’utilise une classe GF pour laquelle j’écris le code CSS suivant qui aligne l’image sur la gauche et prévoit une légère marge pour le texte qui viendra se placer à côté de l’image:

.GF {
   float: left;
   margin-right: 3rem;
}

D’autres exemples

On peut retrouver ici une liste de sites utilisant Scribouilli. Parmi ceux-ci, certains ont également effectué des modifications à l’aide de CSS. Ci-dessous, deux exemples. À gauche, le site de La Frontale qui obtient une impression très différente avec très peu de modification au niveau du CSS. À droite, le site de lahminewski qui est un exemple de modifications plus visibles mais qui restent très simples. On retrouve ici le code CSS qui y est utilisé.

Réflexions concernant le CSS

Les quelques exemples présentés ci-dessus démontrent qu’il n’y a pas besoin de beaucoup de code CSS pour obtenir des effets forts différents les uns des autres. Tout n’est cependant pas possible, Scribouilli apporte une structure de base qui impose parfois quelques contraintes (par exemple concernant la place de la page Articles dans le bandeau supérieur). Si l’on est prêt à utiliser du code HTML dans ses pages, les possibilités de personnalisation augmentent. Comme pour l’alignement des images, le HTML est un passage parfois obligé si l’on a un but précis.

Même si le CSS (ainsi que le HTML) n’est pas très compliqué, on s’éloigne de l’objectif d’avoir un outil simple et facile pour des personnes non versées en informatiques. Rappelons d’abord qu’il n’y a aucune obligation d’ainsi adapter son propre site Scribouilli. Par ailleurs, rien qu’en jouant avec la couleur du site et avec des images, on peut déjà imprimer une personnalité propre à son site. Finalement, si vous accompagnez une personne sans connaissance informatique mais que vous, vous possédez la compétence pour coder le CSS, il est très simple d’écrire quelques règles CSS qui apporte une identité propre au site et puis de laisser la personne se débrouiller par elle-même pour la gestion du contenu proprement dit du blog ou du site.

Il est appréciable que Scribouilli soit à la base utilisable de manière très simple mais que cela n’empêche pas des personnalisations assez importantes pour les personnes qui maîtrisent le CSS et le HTML.

Aider

Scribouilli reste un outil jeune même s’il a quitté son statut de version Beta. La première chose que vous pouvez faire est de tester l’outil et de faire des retours à l’équipe derrière ce sympathique outil. À en croire le site officiel, l’équipe est toujours preneuse de ces retours.

J’imagine que si vous êtes sympathiques et un poil compétents, il y a sans doute moyen de collaborer avec les créateurs de Scribouilli. Contactez-les le cas échéant.

Pour le moment, Scribouilli est développé de manière bénévole. Ce n’est pas prévu pour le moment mais si vous avez très envie de les soutenir financièrement, je suis convaincu que si vous les contactez, il y aura moyen de trouver une possibilité de le faire de manière utile (mais bon, là, je m’avance peut-être un peu).

Conclusion

Désormais, Scribouilli est un outil fonctionnel pour réaliser un site de quelques pages ou pour bloguer. Sans rien y connaître, il est simple de mettre en place son blog ou son site. En s’y connaissant un peu, Scribouilli offre pas mal de possibilités de personnalisation rien qu’avec le CSS. Travailler avec le HTML permet d’aller par ailleurs encore plus loin dans la personnalisation de son site ou blog.