Au cours du développement de l’application PeerTube, nous avons acquis certaines expériences dans le choix des technologies employées et les freins que certaines décisions ont entraîné. Nous les partageons ici.

Si vous ne l’avez pas déjà lu, nous vous conseillons de commencer par l’article précédent.

Publication sur les magasins d’application

Publier une application de streaming vidéo issue du fediverse sur les différents magasins d’applications a été un vrai parcours du combattant.

Entre les politiques parfois très strictes des stores, et la sensibilité autour des contenus vidéo — notamment ceux générés ou diffusés par des tiers — il a fallu redoubler de prudence. Apple et Google considèrent en effet qu’en tant qu’éditeur de l’application nous serions responsables de tout le contenu auquel l’application permet d’accéder, et sont particulièrement virulents sur la question dans le cas des formats vidéos (bien davantage que pour une application de podcasts ou même un navigateur internet, assez curieusement). Voici donc un retour sur les différentes étapes, de la toute première soumission à la mise en production.

Les précautions prises

Pour maximiser nos chances d’être acceptés sur les stores, nous avons pris plusieurs précautions dès le départ.

Filtrage des plateformes accessibles

Première mesure : restreindre l’accès aux plateformes via un système de filtrage utilisant des identifiants spécifiques à chaque magasin. Cet identifiant permet de maintenir une liste d’autorisation (allowlist) de plateformes de confiance adaptée à chaque store :

• Sur le Play Store (Android), seule une allowlist restreinte de plateformes est accessible afin de répondre aux exigences de Google.
• Sur l’App Store (iOS), l’allowlist est encore plus limitée, Apple imposant des critères de validation particulièrement élevés.
• Sur F-Droid, en revanche, toutes les plateformes listées dans notre index (qui est modéré) sont accessibles sans filtrage supplémentaire.

L’avantage de ce système basé sur des tags, c’est qu’il est entièrement déporté côté serveur. Autrement dit, si nous devons retirer une plateforme problématique ou en ajouter une nouvelle, cela peut être fait sans mettre à jour l’application elle-même. Ce fonctionnement offre une grande souplesse et réactivité en cas de besoin.

Pas d’ajout manuel de plateformes au début

Pour garantir une validation rapide lors de la première soumission, nous avons volontairement désactivé la possibilité d’ajouter manuellement une plateforme dans l’application. Ainsi, seuls les serveurs autorisés par notre filtre, dont le nombre était très réduit, étaient disponibles.

Une fois l’application validée et disponible sur le Play Store, nous avons réactivé cette fonctionnalité manuelle côté Android, en observant attentivement si cela posait problème. Après plusieurs mois sans retour négatif, nous avons ensuite ouvert cette possibilité sur iOS également.

Présentation et stratégie de déploiement

Par ailleurs, pour mettre toutes les chances de notre côté, un soin particulier a été apporté à l’interface utilisateur de l’application ainsi qu’aux fiches des stores (miniatures, descriptions, mots-clés, captures d’écran, etc.), les stores étant également très sensibles à l’apparence, à la qualité perçue et au respect des bonnes pratiques UX/UI.

Nous avons décidé d’y aller étape par étape :

1. D’abord le Play Store, plus rapide et souple.
2. Puis l’App Store, plus exigeant mais incontournable.
3. Et enfin F-Droid, qui demande une approche différente essentielle pour le public libriste.

Google Play Store, une validation sans accroc

Pour la publication sur le Google Play Store, la documentation officielle Flutter a été suivie : https://docs.flutter.dev/deployment/android

Le Play Store permet plusieurs types de déploiement, utiles pour tester différentes étapes de l’application :

• Test interne : permet de distribuer l’application à un petit groupe de testeurs internes (jusqu’à 100).
• Test fermé : permet de cibler un groupe restreint plus large via une liste d’adresses email ou un groupe Google.
• Test ouvert : permet à n’importe quel utilisateur de rejoindre le programme de test via un lien public.
• Production : c’est la version stable, publiée pour tous les utilisateurs sur le Play Store.

Les étapes de validation

Chaque type de déploiement est validé automatiquement par Google, avec des délais très courts :

• Les tests internes et fermés sont généralement disponibles en moins d’une heure.
• Les tests ouverts et la mise en production peuvent prendre quelques heures, rarement plus.

Google a toujours accepté l’application dès la première soumission, sans demander de modifications ou poser de questions. Aucun échange, aucun retour de leur part : uniquement la validation après envoi et un changelog bien rédigé.
À croire que les précautions mises en place en amont ont été suffisantes… voire qu’on aurait pu être un peu plus détendus !

Apple App Store, les complications…

Une fois l’étape Google franchie haut la main, direction Apple — réputé pour être nettement plus exigeant.

Comme pour Android, j’ai suivi la documentation officielle Flutter pour le déploiement iOS :
👉 Flutter iOS Deployment

Sur iOS, les applications peuvent être distribuées via deux canaux principaux :

• TestFlight : pour partager des versions bêta avec un groupe de testeurs (jusqu’à 10 000). Le processus est plus souple que pour la production, mais reste soumis à validation.
• Production : la version stable et publique de l’app, visible sur l’App Store.

Les étapes de validation

L’avertissement de Gabe

Avant de soumettre PeerTube sur iOS, nous avons échangé avec Gabe, développeur du projet OwnCast, qui avait essuyé plusieurs refus de la part d’Apple. Il nous a transmis ses précieux retours et stratégies pour répondre aux fameuses App Store Guidelines. Voici un résumé :

• Guideline 1.2 – Safety – User Generated Content
  ➤ Solution : intégrer un système de signalement côté client, qui envoie un email à un modérateur capable de retirer une instance si besoin.
• Guideline 5.2.3 – Legal
  ➤ Problème : Apple considère que l’app pourrait donner accès à des contenus vidéo ou audio tiers sans autorisation, ce qui pose un risque légal.
  ➤ Solution : fournir un document PDF listant chaque serveur vidéo préconfiguré dans l’app, avec la mention “Authorized” pour chacun. Apple ne se satisfait pas d’une simple déclaration : ils veulent des preuves tangibles.

• Guideline 3.1.1 – Business – Payments – In-App Purchase
  ➤ Problème : l’app permettait de faire des dons via des liens comme PayPal, OpenCollective, KoFi, etc.
  ➤ Solution : supprimer toute interaction liée au paiement dans l’app. Tous les liens renvoyant vers des dons doivent ouvrir une page dans un navigateur externe (Safari, Chrome…). Aucun lien de paiement ne doit être affiché dans une WebView interne.
• Guideline 5.2.3 – Legal (bis)
  ➤ Solution : fournir un maximum de documents, liens et preuves que les catalogues et services de découverte intégrés sont bien opérés par nous, et non une tierce partie non autorisée.

Merci encore à Gabe pour ces conseils précieux !

On se lance… et ça coince.

Malgré l’application rigoureuse des conseils de Gabe, Apple n’a pas fait de cadeau.

Entre Lokas et PeerTube, les deux apps que nous tentions de publier fin 2024, nous avons essuyé 8 refus pour Lokas avant d’obtenir la validation, et 3 refus pour PeerTube.

Dès qu’un reviewer Apple trouvait un souci (même mineur), la demande était rejetée, et il fallait corriger point par point avant de pouvoir espérer passer à l’étape suivante.

Voici les principales guidelines qui nous ont posées problème :

Guideline 5.2.3 – Legal

Votre application contient du contenu ou des fonctionnalités susceptibles de porter atteinte aux droits d’un ou plusieurs tiers. Plus précisément, votre application fournit un accès potentiellement non autorisé à des services tiers de streaming audio ou vidéo, à des catalogues et à des services de découverte.

Malgré l’envoi d’un document listant les plateformes autorisées dans l’app iOS, cela n’a pas suffi à convaincre Apple. Nous avons donc répondu :

Les plateformes répertoriées dans l’application PeerTube ont accordé à l’application PeerTube le droit de répertorier et d’accéder à leur contenu vidéo.

Ces autorisations sont répertoriées dans le document « Plateformes autorisées pour l’application PeerTube ».

Pouvez-vous expliquer quel type de preuve nous devons fournir pour démontrer que nous avons le droit d’accéder à ce contenu ?

Le document joint était rigoureusement le même que celui soumis lors du dépôt de l’application.

Guideline 3.1.1 – Business – Payments – In-App Purchase

Apple nous a signalé un lien vers le site joinpeertube.org dans l’app, qui contient… un bouton de don. Ce simple lien externe a suffi à justifier un rejet.

Nous avons alors tenté une première réponse, en expliquant que tous les liens de dons ouvraient désormais une page externe dans le navigateur, et qu’aucune collecte n’était réalisée dans l’application elle-même. Nous avons souligné que cette approche respectait les guidelines de l’App Store, puisque le processus de don était totalement séparé des fonctionnalités de l’app. Malgré cette clarification, Apple n’a pas été convaincu.

En replongeant dans les App Store Guidelines, j’ai repéré un paragraphe en notre faveur :

Section 3.2.2 (iv) : Les applications qui ne sont pas approuvées en tant qu’organisations à but non lucratif ou autrement autorisées en vertu de la section 3.2.1 (vi) peuvent collecter des dons caritatifs en dehors de l’application, par exemple via Safari ou SMS.

J’ai donc renvoyé un message à l’équipe de validation, en expliquant que l’application ne collecte aucun don en interne : tous les liens de soutien ouvrent une page externe dans le navigateur (Safari), conformément à la section 3.2.2 (iv) des App Store Guidelines qui autorise ce fonctionnement pour les apps non caritatives. J’ai ainsi demandé une réévaluation de la décision ou des précisions si d’autres points posaient problème.

🎉 Résultat : l’application PeerTube a officiellement été publiée sur iOS !

Depuis, j’ai soumis 5 mises à jour successives de PeerTube, toutes validées sans accroc — y compris celle qui introduisait la fonctionnalité de connexion.
Chaque mise à jour a été validée en quelques heures, au plus sous 24h.

L’App Store, ce n’est jamais simple… mais avec de la patience et une bonne lecture des guidelines, ça passe.

F-Droid, une autre aventure

Une fois l’étape Apple validée, je me suis attaqué à la soumission sur F-Droid.
Ici, ce n’est pas un problème de guidelines, mais plutôt de processus.

La documentation officielle est plutôt éparse, et j’ai eu du mal à trouver une ressource exhaustive pour un projet Flutter. Je me suis donc appuyé sur :

• La documentation “rapide” : https://f-droid.org/docs/Submitting_to_F-Droid_Quick_Start_Guide/
• La FAQ développeur : https://f-droid.org/docs/FAQ_-_App_Developers/
• Et surtout l’analyse de d’autres applications Flutter déjà présentes sur F-Droid

S’adapter au fonctionnement de F-Droid

F-Droid a des exigences particulières :

• Le build doit être reproductible et entièrement libre.
• Toute dépendance externe doit pouvoir être vérifiée ou supprimée.
• Il faut déclarer les anti-features, c’est-à-dire des limitations qui ne correspondent pas aux idéaux du libre.

Exemple : TetheredNet

L’application PeerTube utilise par défaut deux services maintenus par Framasoft :

• instances.joinpeertube.org pour lister les instances disponibles
• SepiaSearch pour faire des recherches depuis un compte local

Ces services ne sont pas configurables par l’utilisateur, ce qui a été considéré comme une “anti-feature” du type TetheredNet (connexion à un service centralisé sans possibilité de le changer).

Cette mention a donc été ajoutée lors de la soumission initiale.
Bonne nouvelle : depuis, cette anti-feature a été retirée, car nous avons rendu ces services personnalisables dans l’app.

Dépasser le blocage d’une dépendance obsolète

Avant de parvenir à la validation, nous avons rencontré un obstacle lié à une dépendance utilisée pour la gestion de la base de données locale. Cette bibliothèque, pourtant populaire au moment du choix initial, n’était plus maintenue et ne proposait pas de version compatible avec la dernière version de Flutter requise par F-Droid pour garantir la reproductibilité des builds. Ce blocage a empêché la compilation de l’application sur l’infrastructure F-Droid, rendant impossible sa publication.

Après analyse, il est apparu que la meilleure solution, pour des raisons de pérennité et de sécurité, était de remplacer cette dépendance obsolète par une alternative maintenue et compatible avec les exigences de F-Droid. Ce changement a nécessité une réécriture partielle de la gestion des données locales, mais a permis de débloquer la situation et d’assurer la stabilité du projet sur le long terme.

Le merge request de soumission

Après plusieurs itérations, nous avons enfin pu soumettre notre app sur F-Droid.
Vous pouvez consulter la MR ici : https://gitlab.com/fdroid/fdroiddata/-/merge_requests/17235

Et pour voir la configuration finale de l’application PeerTube sur F-Droid (fichier metadata/*.yml) : https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/org.framasoft.peertube.yml

F-Droid demande rigueur et patience, mais l’expérience permet aussi de mieux comprendre les enjeux du libre et de la décentralisation.

C’était un vrai défi, mais on est fier·es de faire partie du catalogue officiel.

Nous en profitons pour vous rappeler que le financement participatif pour le développement de l’application PeerTube est en cours jusqu’au 17 juin 2025 !

Au cours du développement de l’application PeerTube, nous avons acquis certaines expériences dans le choix des technologies employées et les freins que certaines décisions ont entraîné. Nous les partageons ici.

Pourquoi Flutter ?

Le développement d’applications mobiles pose rapidement la question du choix des technologies : faut-il créer une application distincte pour chaque plateforme, ou adopter une approche permettant de mutualiser les efforts ? C’est là qu’intervient le cross-platform : une méthode qui consiste à développer une seule base de code pour cibler plusieurs systèmes d’exploitation, principalement Android et iOS.

Le développement cross-platform présente ainsi de nombreux avantages. Il permet avant tout de réduire considérablement les coûts et les efforts de maintenance, puisqu’une seule base de code est nécessaire, limitant ainsi les corrections de bugs et les mises à jour multiples. Il offre aussi un déploiement plus large et plus rapide, en touchant un public plus vaste sans avoir à développer des applications distinctes.

Comme notre développeur n’était pas initialement spécialisé dans le développement mobile, il a dû se former pour maîtriser les outils nécessaires. Deux technologies principales se sont imposées dans notre réflexion : React Native et Flutter.

Nous avons donc mené une étude comparative afin de choisir la solution la plus adaptée à nos besoins. Après analyse, notre choix s’est porté sur Flutter. Pour plus de détails, vous pouvez consulter l’étude complète en suivant ce lien : https://framagit.org/wicklow/peertube-prototypes

Suite à ce choix, notre développeur s’est lancé dans l’apprentissage et la maîtrise de Flutter. Il vous partage son expérience à travers la suite de cet article.

Apprendre Dart et Flutter

La première étape a été d’apprendre le fonctionnement de Flutter. Les applications Flutter sont écrites en Dart, un langage orienté objet. J’ai donc commencé par explorer la documentation officielle de Dart et Flutter pour comprendre les bases.

Voici les différentes ressources que j’ai utilisées pour m’initier :

• La documentation officielle de Flutter : une excellente introduction officielle pour comprendre les concepts fondamentaux de Flutter.
• Le blog de Flutteris : des articles détaillés et des tutoriels pratiques pour approfondir mes connaissances.
• Code with Andrea : des guides et des exemples concrets pour apprendre à structurer et optimiser mes projets Flutter.

Choisir son architecture

Une fois ces bases acquises, je me suis penché sur la structure idéale pour le projet. Après avoir exploré différentes approches, j’ai opté pour une architecture “Feature First”. Cette méthode consiste à organiser le code par fonctionnalités plutôt que par type de fichier (comme les modèles, les vues, ou les contrôleurs).

L’approche “Feature First” offre de nombreux avantages. Elle apporte une clarté accrue au projet en isolant chaque fonctionnalité dans son propre dossier, ce qui simplifie la navigation et la compréhension de la structure du code. De plus, cette méthode favorise la modularité en rendant les fonctionnalités indépendantes, permettant ainsi leur réutilisation ou leur modification sans affecter les autres parties du projet. Enfin, dans le cadre d’un projet libre, cette organisation facilite la contribution des développeurs externes, qui peuvent se concentrer sur des fonctionnalités spécifiques sans interférer avec le reste du code.

Choisir ses dépendances

Chaque bibliothèque intégrée dans le projet doit être remise en question dans le but de s’assurer qu’elles répondent aux exigences fonctionnelles, qu’elles soient maintenables à long terme et qu’elles n’introduisent pas de risques techniques. Flutter étant une technologie encore jeune, il est important d’être prudent dans le choix des dépendances. Certaines bibliothèques peuvent manquer de maturité ou de soutien communautaire, ce qui pourrait entraîner des bogues ou des problèmes de mises à jour futures.

Voici quelques critères généraux pour choisir une dépendance sur pub.dev :

• Vérifiez le nombre de personnes contribuant activement au projet sur GitHub. Une équipe de contributeur⋅rices plus importante indique souvent un projet plus robuste à long terme.
• Assurez-vous que le projet est actif, avec des commits récents et des demandes régulières, de préférence de la part d’utilisateur⋅rices différent⋅es.
• Regardez le score global sur pub.dev, qui mesure la qualité des paquets.
• Vérifiez la fréquence des publications.
• Donnez la préférence aux paquets publiés par un⋅e éditeur⋅rice vérifié⋅e.

Les dépendances choisies

En prenant en compte ces critères, j’ai soigneusement sélectionné les bibliothèques nécessaires pour le développement de l’application mobile PeerTube.

Voici les principales bibliothèques retenues pour le projet, accompagnées des réflexions qui ont guidé leur sélection :

Le gestionnaire d’état

Un gestionnaire d’état (ou “state management” en anglais) est une approche ou un outil utilisé pour gérer l’état d’une application. Dans le contexte de Flutter, l’état fait référence aux données dynamiques ou aux informations qui peuvent changer au cours de l’exécution de l’application, comme l’entrée utilisateur, les données récupérées d’une API, ou encore l’état d’une animation.

Plusieurs approches et bibliothèques sont disponibles pour la gestion des états dans les applications Flutter, chacune avec ses propres avantages et limitations.

Approches de gestion d’état

• StatefulWidget : le mécanisme intégré le plus simple pour gérer l’état local.
• InheritedWidget : une solution native qui permet de partager l’état entre les widgets.
• Variables globales : une approche où l’état est stocké dans des variables globales qui sont accessibles dans toute l’application.

Les bibliothèques populaires

Provider :

• Pour : simple, léger et largement utilisé par la communauté Flutter.
• Contre : nécessite un code standard et manque de fonctionnalités avancées.

Bloc :

• Pour : hautement structuré, il favorise la séparation des préoccupations et est idéal pour gérer une logique d’application complexe.
• Contre : courbe d’apprentissage abrupte. Nécessite plus de code de base que les autres solutions.

Riverpod :

• Pour : une alternative moderne à Provider avec une API plus simple, une meilleure testabilité et la prise en charge de l’injection de dépendances. Elle supprime les contraintes de l’arbre des widgets de Flutter, ce qui la rend plus flexible.
• Contre : elle est plus récente que les autres bibliothèques, mais son développement est très actif.

Riverpod a été choisi pour sa simplicité, sa flexibilité et son évolutivité, offrant une gestion globale de l’état indépendante de l’arbre des widgets. L’approche de Riverpod avec des variables globales me convient. En outre, l’intégration de la génération de code dans le projet promet d’améliorer les performances à l’avenir. Cependant, il est important de choisir une solution qui correspond à vos préférences et à vos besoins spécifiques.

Le routeur

Un routeur est un composant essentiel qui gère la navigation entre les différents écrans d’une application, permettant de définir les itinéraires, de gérer les transitions, de transmettre des paramètres via les URL, et de prendre en charge les liens profonds.

Plusieurs bibliothèque sont disponibles pour gérer la navigation dans les applications Flutter :

• Navigator : inclus dans le SDK Flutter mais manque de fonctionnalités telles que les liens profonds.
• AutoRoute : permet de générer du code pour simplifier la gestion des itinéraires, mais peut être difficile à configurer.
• GoRouter : une bibliothèque officielle soutenue par l’équipe Flutter, combinant la facilité d’utilisation avec un support avancé de liens profonds.

Après analyse, GoRouter s’est avéré être le meilleur choix pour ce projet, en particulier pour :

• Un support actif de l’équipe Flutter et une documentation complète, garantissant un choix fiable à long terme.
• La prise en charge des liens profonds, essentielle pour rediriger les utilisateurs entre les pages web des plateformes PeerTube et l’application.
• Basé sur l’API Navigator 2.0 incluse dans le SDK Flutter.

Le lecteur vidéo

Le lecteur vidéo est un composant essentiel pour l’application PeerTube, car il constitue le cœur de l’expérience utilisateur. Il était crucial pour nous de faire le bon choix de bibliothèque dès le début pour garantir une lecture fluide, une compatibilité avec différents formats vidéo, et une intégration harmonieuse avec les fonctionnalités de l’application.

Plusieurs bibliothèques sont disponibles et utilisées par la communauté Flutter pour implémenter la fonctionnalité de lecture vidéo :

• video_player : une bibliothèque officielle soutenue par l’équipe Flutter qui fournit des fonctionnalités de lecture vidéo de base, mais nécessite une personnalisation importante pour les fonctionnalités avancées.
• Chewie : une puissante surcouche autour de video_player soutenue par la communauté Flutter qui fournit une interface de lecteur pré-construite et hautement personnalisable et prend en charge les commandes de base telles que lecture/pause, le plein écran et les sous-titres.
• BetterPlayer : un lecteur vidéo avancé construit au-dessus de Chewie, avec des fonctionnalités supplémentaires, mais pas très bien maintenu.
• MediaKit : un ensemble plus récent qui vise à fournir une expérience de lecture vidéo cohérente et riche en fonctionnalités sur toutes les plateformes, bien que son écosystème et le soutien de la communauté soient encore en cours de maturation.

Après analyse, Chewie s’est avéré être notre premier choix en raison de son équilibre entre simplicité et fonctionnalité :

• Facile à intégrer, il fournit une interface de lecture prête à l’emploi avec une configuration minimale.
• Personnalisable, permettant aux développeurs d’adapter l’interface utilisateur et le comportement aux besoins de l’application.
• Maintenu par la communauté Flutter, il garantissait sa fiabilité.

Cependant, après plusieurs mois d’utilisation, nous avons constaté que la maintenance de Chewie était plus faible que prévu. Certaines fonctionnalités et corrections de bugs présentes dans des merge requests n’étaient pas intégrées, ce qui a limité notre capacité à répondre rapidement aux besoins de l’application.

En conséquence, nous avons décidé de migrer vers video_player. Bien que cette bibliothèque nécessite plus de temps pour mettre en place une interface utilisateur personnalisée et des fonctionnalités avancées, elle offre un contrôle plus granulaire et une stabilité accrue. Cette transition nous a permis de concevoir une expérience utilisateur sur mesure tout en garantissant une meilleure fiabilité à long terme.

Les flavors

Nous avions besoin de deux applications distinctes :

• stable : la version en production, destinée à être déployée sur les stores publics.
• nightly : la version intégrant les derniers changements, basée sur la branche de développement.

Les flavors permettent de gérer ces deux versions de manière distincte, en créant deux applications séparées. Pour mettre cela en place, il est nécessaire de configurer les flavors sur chaque plateforme native ciblée (Android et iOS). De plus, chaque application doit être signée séparément pour chaque flavor. Enfin, le code Dart partagé par toutes les plateformes peut être configuré en fonction de l’environnement grâce à l’argument --dart-define-from-file, qui permet de fournir un fichier .env contenant les variables nécessaires.

Exemple de commande pour construire l’environnement stable :

flutter build apk --flavor stable --dart-define-from-file=env-stable.json

Pour plus de détails sur la configuration des flavors et la signature des applications, consultez ce rapport dans lequel nous détaillons comment nous avons mis en place ce système de flavor.

Les erreurs commises

Écrire des tests trop tôt

L’une des erreurs que j’ai commises au début du projet a été de vouloir écrire des tests unitaires et d’intégration dès les premières étapes du développement. Bien que les tests soient essentiels pour garantir la qualité et la stabilité du code, les écrire trop tôt peut s’avérer contre-productif, surtout lorsque l’architecture et les fonctionnalités de l’application ne sont pas encore clairement définies. En effet, au début du projet, de nombreux changements ont été apportés à la structure du code et aux fonctionnalités, rendant ainsi les tests obsolètes rapidement.

De cette expérience, j’ai retenu la leçon suivante : il faut accorder la priorité à la stabilité de l’architecture. Avant d’écrire des tests, il est crucial de s’assurer que l’architecture de l’application est bien définie et stable. Cela permet de réduire le nombre de modifications fréquentes des tests.

Sous-estimer la complexité des dépendances

Nous avons initialement intégré plusieurs bibliothèques sans évaluer pleinement leur maturité et leur compatibilité avec notre projet. Certaines dépendances se sont avérées instables ou mal maintenues, ce qui a entraîné des problèmes imprévus et des retards. Une analyse plus approfondie des dépendances aurait permis d’éviter ces écueils.

Ce parcours d’apprentissage de Flutter m’a ainsi permis de poser des bases solides pour développer l’application mobile PeerTube.

Dans le prochain article, nous aborderons une étape cruciale : la publication de l’application sur les stores (Google Play, App Store et F-Droid). Nous y détaillerons les démarches, les bonnes pratiques et les pièges à éviter pour réussir la mise en ligne d’une application mobile telle que PeerTube.

Nous en profitons pour vous rappeler que le financement participatif pour le développement de l’application PeerTube est en cours jusqu’au 17 juin 2025 !

Grâce à votre soutien, nous (Framasoft, une petite association à but non-lucratif) développons PeerTube depuis sept ans ! D’un projet étudiant à un logiciel d’envergure internationale, notre solution de plateforme vidéo est désormais utilisée et reconnue par de nombreuses institutions !

Bien sûr, nous avons encore beaucoup de chemin à faire, et si la communauté de PeerTube grandit de jour en jour, nous percevons déjà quelques étapes cruciales qui permettraient à PeerTube d’être adopté par un plus grand public !

Avec votre aide, amenons PeerTube dans la poche de toutes et tous !

Soutenir PeerTube

Une application pour toutes et tous !

L’année dernière a marqué un tournant important pour PeerTube. En effet, nous avons engagé Wicklow pour travailler sur l’application mobile PeerTube, doublant ainsi notre effectif dédié au développement de PeerTube.

Oui, ça peut sembler un peu dingue, et pourtant, PeerTube n’a été développé jusqu’à présent que par un seul développeur salarié et une poignée de contributeur·ices bénévoles ! (Merci mille fois à vous ! 💖)

Nous réfléchissions depuis longtemps à construire notre propre application mobile, constatant l’utilisation massive des smartphones pour profiter de contenus vidéos. Grâce à vos votes sur notre plateforme dédiée au partage d’idées concernant PeerTube, nous avons été convaincu·es d’entamer ce chantier et souhaitons aujourd’hui mettre des ressources dedans !

Depuis sa sortie en fin d’année dernière en version préliminaire, l’application a beaucoup évolué et vous pouviez il y a quelques semaines découvrir la première version majeure ! Le détail des améliorations apportées par cette version sont consultables dans l’article de blog dédié.

Une bulle d’autonomie hors du système YouTube-Twitch-Vimeo

Plus qu’une application mobile, PeerTube est un écosystème vibrant : 1300 plateformes recensées, totalisant 300 000 comptes utilisateurices et 756 000 vidéos. 

Outre les nombreuses autres améliorations, la version 7 a apporté un nouveau design, pensé pour être plus moderne, accessible et mieux adapté pour les institutions.

Parmi ces institutions, nous retrouvons notamment le Ministère de l’Éducation Nationale français ou le GARR (réseau informatique des universités italiennes).

Pour toutes ces raisons, nous considérons que PeerTube est désormais un logiciel mature

(même si, oui, il y a toujours moyen de l’améliorer et nous allons œuvrer dans ce sens ! 😛)

Nous voyons en PeerTube un logiciel émancipateur, permettant un partage non-marchand des vidéos.

Que vous souhaitiez partager vos vidéos avec vos élèves, publier vos tutoriels de jardinage facile, ou avoir une plateforme vidéo autonome pour votre structure, tout est possible avec PeerTube !

Popularisons les vidéos et lives partagées par des humain·es, pour des humain·es !

Pour permettre à encore plus de personnes d’accéder à PeerTube, nous sommes ravi·es d’annoncer le lancement d’une campagne de financement participatif ! 🎉

Notre feuille de route pour la partie Web de PeerTube étant déjà financée, nous voulons concentrer sur l’amélioration de l’application mobile. Nous aimerions y apporter des fonctionnalités clés pour qu’elle facilite l’apport de contenus.

Ensemble, allons plus loin en amenant PeerTube dans les poches de tout le monde !

Quatre objectifs collectifs

PeerTube est pensé comme un commun, un outil appropriable par toutes et tous. Nous souhaitons développer l’application dans ce sens et avons donc pensé à quatre objectifs-clés nous permettant de nous en rapprocher.

Contrairement à la plupart des financements participatifs, nous ne proposons pas de « contrepartie » pour votre don. En soutenant PeerTube, votre récompense, c’est d’avoir contribué à un Commun, qui sert à toutes et appartient à tous.

Cependant, nous avons joué avec le concept, et vous proposons différentes « contributions » possibles, pour vous montrer le travail que votre soutien nous permet de réaliser.

15 000€ – Un PeerTube « Premium » gratuit pour toustes

Cet objectif permet de débloquer un « PeerTube Premium »… mais gratuit et pour tout le monde !

• Lisez la vidéo en fond pour pouvoir continuer d’écouter une conférence ou un cours sans interruption, même si vous avez besoin d’aller jeter un coup d’œil rapide à un document

• Diffusez les vidéos sur votre télévision et montrez à vos ami·es le tutoriel vidéo super utile pour votre association

• Recevez des notifications sur les nouveaux contenus publiés afin de ne plus manquer les sorties de votre vidéaste préféré·e

• Changez la définition de la vidéo et économisez ainsi votre forfait data

Tout ça, sans publicité ! La magie d’une application pensée pour vous servir, pas pour vous pister ! 🪄

35 000€ – Partager des vidéos depuis votre poche

Parfois, vous n’avez pas de grosse édition à faire sur vos vidéos et souhaitez juste les téléverser rapidement sans passer par votre ordinateur.

C’est ce que vous permettra cet objectif !

• Gérez toutes les chaînes de votre compte, directement dans l’application

• Modifiez les chapitres, sous-titres et autres informations de vos vidéos

• Consultez les statistiques détaillées de votre contenu : combien de personnes regardent vos vidéos, pendant combien de temps, à partir d’où, etc.

• Téléversez de nouvelles vidéos avec votre téléphone

Est-ce qu’il faut que l’application réponde aux besoins des vidéastes…? À vous de nous le dire, car nous avons bien envie de développer ces fonctionnalités d’ici à la fin de l’année.

55 000€ – Diffuser en live depuis votre téléphone

Pour que vous puissiez aussi bien partager en direct un mouvement social ou votre découverte de Séoul !

• Configurez et gérez vos diffusions en direct sur votre téléphone, sans passer par OBS ! 😎
• Utilisez votre périphérique et sa connexion, pas de matériel supplémentaire requis
• Diffusez en live du bout des doigts, sans avoir besoin d’ordinateur
• Plus besoin d’application secondaire dédiée aux lives, retrouvez tous vos besoins au même endroit !

Nous imaginons déjà les directs partagés depuis une manifestation, une conférence, un débat associatif. Néanmoins, si cet objectif est financé, nous n’envisageons pas le finir avant fin de l’année, et tablons sur une publication en 2026.

75 000€ – Soutenir Framasoft & PeerTube

PeerTube est un projet majeur dans l’histoire de Framasoft, mais il n’est pas le seul. Si Framasoft a pu développer PeerTube, c’est parce que notre association a été soutenue pour ses autres actions, par des dons.

Soutenir Framasoft, c’est ainsi contribuer à la construction d’un numérique solidaire, émancipateur et non-marchand.

 

• Nous ne faisons pas de profit : nous fournissons des Communs

• Tous les dons financent tous nos projets, à la fois PeerTube mais aussi des dizaines d’autres

• Nous maintenons PeerTube, avec un support gratuit et de qualité — ce travail de l’ombre, quotidien, se fait en plus des nouveaux développements

• Nous dégooglisons plus de 2M de personnes par mois, en leur fournissant des services web qui permettent de s’émanciper des géants du numérique

Nous détaillerons chacun de ces objectifs dans des articles de blog dédiés, très prochainement ! Comme on dit dans le Bouchonnois : Stay Tuned!

Contribuer aux communs : un cercle vertueux !

En contribuant, vous ne donnez pas seulement pour l’application mobile PeerTube, mais pour l’ensemble des projets de Framasoft !

Voici un graphique montrant, dans le détail, la manière dont nous utilisons cet argent. Si vous souhaitez plus de détails, vous pouvez aussi consulter notre rapport financier.

Ce financement participatif est vraiment important pour nous car non seulement il nous permet de sécuriser l’argent nécessaire au développement du projet, mais aussi d’estimer l’enthousiasme du public pour l’application mobile et le projet PeerTube en général !

Cependant, soyons clair·es ! Nous chercherons à réaliser les améliorations proposées dans cette collecte que nous parvenions à nos objectifs ou non !
Si les objectifs de collecte ne sont pas remplis, nous devrons piocher dans les dons faits par la communauté francophone en fin d’année dernière pour l’ensemble des projets de Framasoft. Cela nous signifiera que notre enthousiasme pour PeerTube et son application n’est pas partagé. (Ça arrive, parfois ! 🤷‍♀️)
Nous nous demanderons alors s’il faut vraiment ajouter l’envoi de vidéos (ou les live) dans l’application, mais surtout s’il faut lever le pied dans notre stratégie de populariser l’écosystème PeerTube.

Votre soutien est notre boussole : à vous ne nous dire si vous partagez notre enthousiasme !

Soutenir PeerTube

Soutenez l’écosystème PeerTube en partageant votre attention…

L’écosystème de PeerTube dépasse le seul giron de Framasoft. Mois après mois, de plus en plus de personnes ou structures s’approprient le projet et le font vivre !

Grâce à un système d’extensions puissant, des développeurs et développeuses volontaires ne cessent d’étendre les fonctionnalités du logiciel. Le catalogue d’extensions de PeerTube comporte plus de 200 extensions, chacune permettant d’ajouter des fonctionnalités de PeerTube ou de modifier son apparence !

Côté communauté, celle-ci s’enrichit de différentes initiatives inspirantes !

C’est le cas, par exemple, du compte Mastodon Fedi.Video qui, depuis des années, aide à visibiliser les vidéastes publiant sur PeerTube !

Aussi, des plateformes spécialisées se développent, à l’image de MakerTube, dédiée à celles et ceux « qui font ».

Nous ne pouvons évidemment lister dans cet article toutes les initiatives géniales que nous repérons, mais nous tenons à vous dire un immense bravo à toustes pour votre travail formidable. Merci d’enrichir PeerTube de vos couleurs ! 🫶

Si vous souhaitez en savoir d’avantage sur l’écosystème PeerTube, vous pouvez vous inscrire sur la newsletter PeerTube. Vous recevrez ainsi des informations concernant les avancées du projet mais aussi sur les initiatives de la communauté !

Vous pouvez aussi suivre le compte PeerTube (et Framasoft) sur les médias sociaux (Mastodon et BlueSky) :

• PeerTube sur Mastodon

• Framasoft sur Mastodon

• PeerTube sur BlueSky

• Framasoft sur BlueSky

En plus des informations ponctuelles, nous y publions chaque semaine des astuces pour utiliser PeerTube !

…et en nous aidant à récolter les fonds !

Nous nous donnons 3 semaines pour, collectivement, financer nos actions pour populariser PeerTube.

Nous croyons sincèrement que nous pouvons y parvenir car nous sommes convaincu·es que PeerTube est un Commun qui vous importe autant qu’à nous !

Alors si vous aussi souhaitez voir advenir un monde où PeerTube est utilisé par toutes et tous, soutenez-nous en faisant un don (si vous le pouvez) et en diffusant le site de la campagne autour de vous !

Ensemble, ré-approprions nous les plateformes vidéos !

Soutenir PeerTube

Framasoft vous propose d’essayer le prototype de Lokas, une nouvelle application de transcription « speech to text » qui respecte votre vie privée. Cette démo fonctionnelle est aussi une expérimentation de Framasoft dans le domaine de l’IA, accompagnée du site Framamia, que l’on présente ici.

Facilitez vos prises de notes avec Lokas

Lokas est une application (sur smartphone Android ou iOS) qui permet de transcrire le son de voix en fichier texte.

En gros, pour une réunion : vous mettez le téléphone au centre de la table, vous appuyez sur le bouton « Enregistrer » en début de réunion, sur « Arrêter » en fin de réunion, et l’application vous renvoie quelques minutes après un fichier texte reprenant les phrases prononcées par chacun et chacune.

Lokas permet et surtout permettra pas mal d’autres choses, mais nous y reviendrons en fin d’annonce.

Lokas, c’est pour qui ?

Lokas s’adresse à toute personne qui participe à des réunions. Autant dire un paquet de personnes sur la planète 🙂

Nous pouvons cependant partager quelques cas d’usages.

Premier exemple : une AG associative

Imaginons une Assemblée Générale associative. Il y a 15 personnes dans la pièce, 2 animateur⋅ices, 1 personne à la prise de notes. Et une réunion de 2H.

Les soucis :

• La prise de notes est épuisante

• La personne qui prend les notes voit sa participation limitée

• Les notes peuvent être incomplètes (un « trou » dû à une pause pipi)

Ce qu’apporte Lokas ?

Lokas permet d’assister la personne qui prend les notes, et lui permettra de participer plus facilement (tout en autorisant la pause pipi !).

Second exemple : un atelier avec des ados

Un atelier de l’association « Les petits débrouillards ». 3 groupes de 5 adolescent⋅es. Une majorité de filles dans les groupes.

Les soucis :

• La prise de notes peut être très compliquée

• Les garçons monopolisent la parole

Ce qu’apporte Lokas ?

Lokas permet de garder trace (sonore et écrite) de ce qu’il s’est dit. Et permet d’établir des statistiques de temps de paroles, notamment par genre, afin d’objectiver le fait que les garçons ne laissent que peu de temps de paroles aux filles.

Troisième exemple : une réunion de travail en visio, en langue étrangère

Votre collectif militant est proche d’une association espagnole. C’est Camille, une bénévole de votre collectif, qui parle à peu près l’espagnol, qui fera la visio avec son interlocutrice madrilène. La visio a donc lieu dans une langue étrangère.

Les soucis :

• Vous avez besoin de pouvoir réécouter à tête reposée

• Vous avez besoin d’une transcription en français et de la partager aux membres du C.A.

Ce qu’apporte Lokas ?

Avec Lokas, Camille pourra réécouter la visio, la transcrire automatiquement en français, et la partager depuis votre smartphone (par mail, via Signal, Matrix, WhatsApp, Telegram, etc).

Soutenir Lokas (et Framasoft)

L’IA n’est pas magique ✨. Lokas non plus 🤷.

Lokas n’est qu’un outil. Il peut vous assister dans la prise de notes. Cependant, comme tout outil, il ne doit pas vous dispenser d’utiliser votre cerveau !

L’invention de l’écriture (une autre technologie, très perfectionnée) date d’au moins 3 000 ans. Cela fait donc au moins aussi longtemps que l’humanité est capable de se réunir et de garder des traces écrites. Sans IA. Sans smartphone. Ne jetez pas plusieurs millénaires de techniques avec l’eau de l’IA. Un outil comme Lokas pourra être utile dans certains cas, et complètement gadget, voire improductif, dans d’autres cas. Cela n’est pas sans rappeler le concept de Pharmakon, cher au philosophe Bernard Stiegler : Lokas, comme tout objet technique, est à la fois poison, remède, et bouc-émissaire.

Par exemple le web est « à la fois un dispositif technologique associé permettant la participation et un système industriel dépossédant les internautes de leurs données pour les soumettre à un marketing omniprésent et individuellement tracé et ciblé par les technologies du user profiling. ». Remède et poison.

De la même façon, Lokas pourra être émancipateur (en facilitant la participation plutôt que la prise de notes), ou au contraire contraignant (les réunions un peu foutraques dans un bar bruyant ont aussi leur intérêt, il ne faudrait pas s’en passer parce que l’outil fonctionne mieux dans un environnement calme), ou frustrant (« l’application a planté, je n’ai aucune note de secours ! La technologie, c’est de la mârde ! »).

Lokas, comme une voiture, un marteau, un stylo, n’est pas un outil « neutre ». À vous de voir, collectivement, si vous souhaitez l’utiliser, et comment.

« C’est l’histoire d’une app… »

Il nous semble intéressant de pouvoir vous raconter comment est née l’application Lokas. C’est lever un coin de rideau sur les coulisses de Framasoft, comprendre comment nous pouvons prendre la décision de faire (ou de ne pas faire) tel ou tel projet. C’est aussi montrer que parfois, avec un peu de chance et d’huile de coude clavier, on peut faire des choses qui pourraient paraître impossibles. Cependant, comme cette partie n’est pas indispensable, on vous laisse le choix d’en prendre connaissance ou pas.

Cliquez ici pour lire (l’improbable et fabuleuse) histoire de Lokas

 

Cela fait bien trois ou quatre ans que l’idée de Lokas traîne dans la tête de pyg, membre de Framasoft.

L’idée de départ (nom de code : « Brewawa »), c’était surtout d’imaginer une application qui serait capable de calculer le temps de parole de locuteur⋅ices dans une réunion. Le but (pas du tout caché) était de démontrer facilement que lors d’une discussion avec des personnes de genres différents, ce sont de façon très très majoritairement les hommes qui monopolisent la conversation.

Différents essais ont été réalisés ces dernières années (coucou Gee, coucou bjnbvr !) pour étudier la faisabilité d’une telle application. Mais le fait est qu’en 2020, même si les possibilités techniques étaient présentes, elles n’étaient pas vraiment accessibles pour notre toute petite association, surtout sur un projet parallèle à tous ceux que Framasoft menait déjà.

« C’est l’histoire d’améliorations techniques… »

Cependant, avec le développement de logiciels tels que Vosk ou Whisper, les capacités de transcription audio (c’est-à-dire la capacité à transformer le son de phrases en texte) se sont largement améliorées.

À tel point qu’aujourd’hui, ces technologies sont utilisées par énormément de logiciels (de YouTube à PeerTube, en passant par BigBlueButton ou WhatsApp), et souvent même directement intégrée dans des appareils (Samsung en fait clairement un argument de vente).

Par ailleurs cette dernière décennie a aussi vu s’améliorer les processus de « diarisation ». Ce terme un peu barbare est en fait la technique qui permet d’identifier différent⋅es locuteur⋅ices dans une discussion. Par exemple, si Alex, Camille et Fred font une réunion, la diarisation saura attribuer à chacun⋅e les phrases qu’il ou elle aura prononcées (non, le logiciel ne va pas deviner le prénom de la personne, mais il saura – à peu près – identifier qu’il y avait trois participant⋅es, et dire « Cette phrase a été prononcée par la personne #1. Cette phrase a été prononcée par la personne #2. », etc.

C’est évidemment une phase essentielle pour pouvoir comprendre « qui a dit quoi » dans une réunion.

Ce processus est encore imparfait, mais s’améliore de mois en mois. Il faut donc se projeter en 2026 ou 2027 pour imaginer une diarisation vraiment fiable, mais elle est aujourd’hui « suffisante » dans 60 à 80% des usages en « bonnes conditions ».

« C’est l’histoire d’un alignement de planètes… »

Il se trouve qu’au sein de Framasoft, les compétences nécessaires pour le développement d’une telle application étaient réunies.

Chocobozzz, le développeur de PeerTube, avait déjà beaucoup travaillé sur le processus d’intégration de Whisper à PeerTube, afin de pouvoir générer automatiquement les sous-titres d’une vidéo. Il connait donc bien Whisper, ses options de configuration, ses performances, etc.

Wicklow, le développeur de l’application PeerTube, travaille depuis plusieurs mois avec le langage Dart et le SDK Flutter qui permet de développer en une seule base de code une application pour différents terminaux (Android, iPhone, ordinateur/tablette, web, etc).

Luc, notre administrateur système préféré (c’est pas compliqué, remarquez, nous n’en avons qu’un 😅) gère l’intégralité de l’infrastructure technique de Framasoft (une soixantaine de serveurs informatiques physiques). Donc, mettre en place la machine qui gère les transcriptions, l’installer, la sécuriser, etc, était pour lui un jeu d’enfant.

pyg, anciennement directeur de Framasoft, aujourd’hui coordinateur des services numériques de l’association, a géré d’innombrables projets pour Framasoft ces 20 dernières années. Alors, un de plus, même en pleine campagne, ça n’allait pas l’arrêter.

Entre cet ensemble de compétences, et les capacités techniques des logiciels de transcriptions et diarisation, les planètes étaient donc alignées pour lancer un tel projet.

« C’est une histoire de chance… »

Cependant, comme souvent, il faut un peu compter aussi sur le hasard ou la chance.

En effet, pyg avait un peu laissé tomber l’idée de cette application, tout simplement par ignorance des avancées techniques en termes de diarisation.

C’est en évoquant l’idée de cette application lors du dernier Framacamp, en juillet 2024, que Wicklow a lâché une info au détour de la conversation : « Ah, mais tu sais, Whisper fait maintenant une diarisation correcte. »

BIM 💣

 

« Ah, super intéressant ! Mais j’imagine qu’il faudrait longtemps pour développer une telle application de transcription libre ? » lui demanda pyg.

« Oh, je dirais qu’en 3 jours, je peux avoir un prototype fonctionnel si Chocobozzz se charge de la partie serveur. »

BOUM 💥

Autant vous dire qu’au lieu de profiter de sa soirée à jouer au poker, pyg a filé dans sa chambre, préparé une présentation d’une douzaine de diapositives sur un potentiel projet d’application, qu’il a présenté à l’association le lendemain matin.

 

Certain⋅es membres étaient enthousiastes, d’autres moins. Et on les comprend : d’une part, c’était encore ajouter du travail à une association déjà particulièrement chargée et épuisée ; d’autre part, c’était un projet utilisant un logiciel issu de l’intelligence artificielle, une technologie sur laquelle nous sommes (unanimement) très critiques.

Cependant, cette application, qui allait devenir Lokas, nous semblait un bon moyen « d’incarner » l’objet social de Framasoft : faire de l’éducation populaire aux enjeux du numérique et des communs culturels.

Cela nous permettait en effet de sortir de l’aspect discours pédagogique, à la fois indispensable, mais insuffisant en termes d’appropriation et d’autodétermination. En créant un « objet numérique manipulable », nous pouvions faire de Lokas une occasion complémentaire de faire comprendre ce qu’est l’IA, ses possibilités, mais aussi ses faiblesses. Et revenir, donc, à notre « Pharmakon » évoqué plus haut.

Par ailleurs, en plus de pouvoir assister tout collectif faisant des réunions, cela nous permettait de mettre en œuvre, concrètement, une application portant nos valeurs : un outil convivial, n’exploitant pas les données des utilisateur⋅ices, sous licence libre, s’adressant avant tout aux personnes qui changent le monde pour plus de progrès social et de justice sociale.

Au final, la majorité des membres présent⋅es s’est exprimée : « Banco la caravane ! On se lance ! ».

« C’est (aussi) une histoire de contraintes »

Comme évoqué plus haut, les contraintes étaient fortes.

Un projet, ça coûte forcément en temps et en argent. Du temps et de l’argent qui ne pourront pas être utilisés ailleurs.

Or, il ne vous a pas échappé que Framasoft vit des dons. Il faut donc faire des campagnes de dons. Et la fin de l’année était déjà particulièrement chargée par la finalisation de différents projets et leurs annonces

En discutant avec Thomas et Pouhiou, codirecteurs de l’association, il a donc été décidé que Lokas devrait rester un projet sous contraintes fortes : coûter moins de 10 000€ tout compris ; ne pas impacter fortement les missions de Chocobozzz, pyg, ou Wicklow ; être réalisé (à « temps perdu », donc) entre mi-septembre et mi-novembre (notamment à cause des délais de validation des stores Android et iOS, que nous ne maîtrisons pas).

Avec de telles contraintes, impossible pour nous de réaliser un produit bien finalisé. Nous avons donc décidé de viser plutôt la mise à disposition d’un prototype. Voyez ce prototype comme un appartement témoin. Nous avons produit cette version non pas en nous focalisant sur un projet de long terme, avec des fondations solides, mais plutôt comme une « preuve de concept », développée rapidement, pour voir si le concept est suffisamment attirant et intéressant pour qu’en 2025 nous priorisions le développement de cette application (si les dons sont suffisants, donc !).

Afin de vous donner suffisamment « envie » de voir un jour une version 1.0 de Lokas arriver, nous avons fait appel aux compétences de l’Atelier Domino pour la création d’un logotype et d’une charte graphique. Ce qui nous a guidés pour réalisé en interne le site web du projet : lokas.app

En parallèle, Wicklow et Chocobozzz se sont attaqués au développement du prototype, ainsi qu’à la partie serveur de transcription.

« C’est une histoire qui ne demande qu’à être écrite… »

Une quinzaine de jours de travail plus tard (et un coût estimé à 7 500€ tout compris, avec en gros moitié de temps de travail Framasoft, et moitié prestations : Atelier Domino, location du serveur, des noms de domaines, validation des stores), nous pouvons présenter, avec fierté et un peu d’anxiété, notre prototype !

Soutenir Lokas (et Framasoft)

Lokas, comment ça marche ?

1. Se mettre dans les bonnes conditions

Lokas, comme tous les outils de transcription, d’ailleurs, est imparfait. Des bruits extérieurs, une mauvaise articulation, une voix fluette en fond de salle, des personnes qui se coupent la parole… Autant de raisons qui peuvent nuire à la transcription.

En conséquence, prévoyez de vous mettre au calme, de placer le téléphone au centre de la table (meilleure est la qualité sonore, meilleure est la transcription), n’ayez pas plusieurs discussions en même temps, et… prenez des notes « à l’ancienne » à côté (papier+crayon, ordinateur+pad, etc) en cas de souci.

Une fois cela fait, le fonctionnement est très simple.

2. Lancer l’enregistrement

Cliquez simplement sur le bouton « Enregistrement ». Placez le téléphone de façon à ce qu’il puisse capter au mieux les échanges. Et commencez votre réunion.

Afin de limiter les abus, les enregistrements sont limités à 5 par jour et par appareil.

Notez que le modèle de langue géré par Lokas permet de l’utiliser d’ores et déjà dans une cinquantaine de langues, notamment : Néerlandais, espagnol, coréen, italien, allemand, thaïlandais, russe, portugais, polonais, indonésien, mandarin, suédois, tchèque, anglais, japonais et bien entendu français ! D’autres langues sont supportées, mais la reconnaissance sera moins performante.

À la fin de la réunion, cliquez sur « Finaliser ».

3. Envoyez votre fichier pour transcription (et patientez)

Vous pourrez éventuellement réécouter votre fichier avant de cliquer sur « Envoyer ».

Votre fichier est alors envoyé sur notre serveur où il sera placé dans la file d’attente pour sa transcription.

Cette étape pourra prendre de quelques minutes à quelques heures, suivant le nombre de fichiers en attente.

Vous pourrez vérifier manuellement si votre fichier a bien été transcrit, ou attendre tranquillement la notification (dont la tâche de vérification est exécutée toutes les 15mn)

Une fois la transcription reçue

Une fois la transcription reçue, vous pourrez l’afficher dans Lokas.

Vous pourrez évidemment la partager (avec l’application de votre choix : mail, Signal, WhatsApp, etc) pour la corriger.

Vous pourrez aussi voir les statistiques de temps de parole (NB : cette fonctionnalité est relativement expérimentale). Si vous le souhaitez, pour une meilleure lecture des notes, vous pouvez attribuer un prénom (ou pseudo) aux participant⋅es. Pour obtenir des temps de parole par genre, vous pouvez aussi les attribuer manuellement, en vous assurant évidemment du consentement des personnes concernées à communiquer cette information. Notez que ces informations sont volontairement manuelles, et ne quittent pas votre téléphone, et ne sont donc pas transmises à Framasoft ou qui que ce soit.

Point confidentialité : l’une des particularités de Lokas est que nous respectons votre vie privée : le fichier audio est enregistré sur votre téléphone. Il est envoyé, à votre demande, sur nos serveurs, qui se chargeront alors de sa transcription. Une fois la transcription terminée, une notification est envoyée sur votre téléphone ; lorsque vous ouvrez (dans « Mes fichiers ») la réunion en question, la transcription est alors téléchargée sur votre téléphone. Une fois cette étape réalisée, et après un léger délai pour s’assurer que tout s’est bien passé techniquement, tout est supprimé de notre serveur : le fichier audio ainsi que la transcription. Par ailleurs, si vous attribuez des noms, pseudos ou genres, pour les statistiques, sachez que ces informations ne font l’objet d’aucun traitement de notre côté.

Soutenir Lokas (et Framasoft)

Et l’IA dans tout ça ?

À Framasoft, nous ne sommes pas fans du tout de l’IA. Nous pensons que cette technologie (ou plutôt cet ensemble de technologies), pose plus de problèmes qu’elle n’apporte de solutions. Nous avons d’ailleurs essayé de présenter une synthèse de notre position sur l’I.A. au sein du site Framamia, que nous présentons ici sur le Framablog.

Alors, n’est-ce pas contradictoire d’utiliser l’IA au sein d’applications Framasoft, comme Lokas ou PeerTube ?

À notre sens, non. Et ce pour plusieurs raisons.

D’abord, comme nous l’écrivions dans le site Framamia, tous les modèles d’intelligence artificielle ne se valent pas. Whisper, le logiciel qui sert à la transcription, est une IA « spécialisée », et non une IA « généraliste » comme ChatGPT par exemple.

« Les modèles spécialisés, quant à eux sont optimisés pour résoudre efficacement une tâche précise. Leur impact est souvent maîtrisé, et peut correspondre à celui d’un autre logiciel. ».
Framasoft, sur le site Framamia.org

Whisper est certes une IA, mais qui tourne « en vase clos » sur nos serveurs.

Les algorithmes utilisés sont plus complexes qu’un filtre « Enlève les yeux rouges de cette photo » avec GIMP ou Photoshop, mais cela reste un modèle relativement simple (avec un processus d’entrées/sorties) infiniment moins énergivore qu’un modèle d’entraînement. En effet, l’inférence (le processus d’utiliser le modèle pour effectuer une tâche) consomme bien moins d’énergie que l’entraînement. Par exemple, exécuter Whisper pour transcrire un fichier audio de quelques minutes nécessite une puissance de calcul relativement modeste.

Ensuite, un projet comme Lokas ne nécessite pas d’acheter 350 000 puces GPU pour 9 milliards de dollars, comme l’a fait récemment Meta/Facebook, ce qui représente en gros le PIB du Togo en 2023. Nous ne pensons pas participer à la croissance de la bulle financière autour de l’IA, ou à faire faire s’emballer le capitalisme algorithmique.

Enfin (et surtout), avec Lokas ou PeerTube, nous demeurons cohérent⋅es avec une des valeurs au cœur de Framasoft, à savoir le respect de la confidentialité de vos données. En effet, nous ne faisons aucune exploitation de vos fichiers, en dehors de la tâche explicitement demandée, par exemple la transcription. Elles ne servent pas à enrichir un modèle d’IA à partir de vos discussions, de votre identité, etc. Nous ne conservons pas les fichiers audio ou texte, nous n’avons pas accès aux noms/prénoms/genres que vous attribuez manuellement aux participant⋅es d’une discussion (ça reste sur votre téléphone), etc. Et, évidemment, vos données ne sont JAMAIS monétisées.

Bref, Framasoft se fiche du contenu de vos données, elles vous appartiennent et ne regardent que vous.

Malgré cela, nous respectons le point de vue des personnes qui souhaitent boycotter l’IA, et nous entendons la contradiction qu’iels pourraient trouver à ce qu’une asso technocritique comme Framasoft propose des projets utilisant l’I.A.

Notre objectif est justement de proposer un outil qui permette d’avoir une réflexion concrète, afin de se forger un avis autonome, permettant à chacun et chacune de se construire sa propre position.

Lokas c’est pour quand ?

Vous pouvez d’ores et déjà télécharger l’application Lokas sur le Play Store, iOS (toujours en testflight chez Apple, parce qu’ils sont 🤬… disons tatillons. EDIT : c’est maintenant disponible !), f-droid (en cours), ou avoir l’apk Android en téléchargement direct ici. Notez cependant que Lokas est un prototype (si ce n’est pas déjà fait, prenez deux minutes pour lire « L’histoire de Lokas » et comprendre pourquoi), et il est donc normal que plein plein plein de choses ne fonctionnent pas !

Nous avons déjà pris du temps, de l’énergie, et un peu d’argent sur des ressources pourtant limitées (on vous a déjà dit qu’on ne vivait que de vos dons ? 😉 ). De plus, comme toujours, le code est libre, nous l’avons publié ici sur notre forge logicielle.

Avant d’aller plus loin, nous avons donc besoin de confirmer que ce projet vous intéresse. Si les dons ne sont pas assez importants, ou si les contradictions sont trop fortes : nous nous arrêterons là. (le code est libre, donc ça ne sera pas « perdu »).

Si, par contre, vous trouvez ça pertinent, les possibilités de développements futurs sont innombrables. Citons par exemple :

• Reprendre complètement le design et l’accessibilité (en mode prototypage, nous sommes allé⋅es très vite, et Lokas est donc très perfectible) ;

• Possibilité de (re)transcrire le fichier de son choix (par exemple issu d’une vidéo ou d’une autre application) ;

• Ajouter un mode « web » à l’application. C’est à dire la possibilité d’utiliser Lokas depuis son ordinateur (sur le modèle de ce que fait le serveur Scribe de nos ami⋅es des Céméa) ;

• Ajouter la possibilité de synthèses automatiques des transcriptions, pour retrouver rapidement les points clés ;

• Traduire l’application (et le site web) dans d’autres langues que le français et l’anglais ;

• Possibilité d’éditer et corriger la transcription directement depuis votre téléphone ;

• Donner la possibilité d’obtenir la transcription dans la langue de son choix (par exemple une réunion en anglais, transcrite en français, ou l’inverse) ;
• etc

Mais pour cela, il va nous falloir du temps salarié, et donc de l’argent. Donc, au risque de paraître insistant, nous vous invitons, si vous le pouvez, à nous faire un don.

Faire une don pour soutenir Lokas

Le défi : 20 000 fois 20 € de dons pour les 20 ans de Framasoft !

Framasoft est financée par vos dons ! Chaque tranche de 20 euros de dons sera un nouveau ballon pour célébrer 20 d’aventures et nous aider à continuer et décoller une 21^e année.

Framasoft, c’est un modèle solidaire :

• 8000 donatrices en 2023 ;
• plus de 2 millions de bénéficiaires chaque mois ;
• votre don (défiscalisable à 66 %) peut bénéficier à 249 autres personnes.

À ce jour, nous avons collecté 58 625 € sur notre objectif de campagne. Il nous reste 29 jours pour convaincre les copaines et récolter de quoi faire décoller Framasoft.

Alors : défi relevé ?

Obtenir Lokas Soutenir Framasoft

Notre petit dossier sur l’application de contact-tracing « StopCovid » s’enrichit aujourd’hui d’un article de Stéphane Bortzmeyer, que nous avons déjà invité à de multiples reprises sur le Framablog.

La position de Framasoft au sujet de cette application est plutôt claire : StopCovid est un leurre de communication politique.

Cependant, nous trouvons important d’apporter au débat des articles plus pédagogiques. Ce que nous avons fait par exemple en publiant la bande dessinée de Nicky Case, et aujourd’hui avec cet article qui, nous l’espérons vous éclairera un peu plus dans le débat.

(NB : cet article est une republication, avec l’accord de son auteur, de l’article https://www.bortzmeyer.org/tracking-covid-19.html dont la première publication est datée du 19 avril 2020 – Nous vous encourageons à vérifier sur le site originel si l’article a pu être mis-à-jour depuis).

Ou plutôt pas de traçage du tout ? Oui bien sûr, ce serait sans doute la meilleure solution compte tenu des inévitables « glissements » que redoute comme nous Hubert Guillaud dans cet article.

Mais à l’heure même où se profile l’appli gouvernementale, véritable agneau innocent qui sera inévitablement converti un jour prochain en outil d’espionnage pur et simple, voici une proposition alternative de protocole qui permettrait de freiner la diffusion de la pandémie et d’échapper à la surveillance invasive.

Voici pour comprendre le principe de cette application une bande dessinée, qui est l’œuvre de Nicky Case (son site – son patreon), elle est destinée à expliquer le fonctionnement du protocole DP-3T à un public plus large. Elle n’est pas une représentation exacte du protocole, comme elle le précise :

Cette BD présente des aspects qui vont au-delà des spécifications de notre protocole, tels qu’un score de risque lié à une instruction de rester à la maison, un exemple ludique de ce à quoi pourrait ressembler un algorithme de calcul de risque local.

Bien que notre protocole soit conçu pour protéger la vie privée et pour contribuer à protéger un large éventail de libertés contre les détournements de fonction, il nécessite un déploiement réfléchi dans un environnement avec des politiques informées et protectrices des droits de l’homme afin de fonctionner pour tous les membres de nos communautés.

La bande dessinée ne doit donc pas être lue comme fournissant des suggestions de politiques au-delà du protocole de l’équipe DP-3T.

Pour celles et ceux qui veulent aller plus loin, beaucoup de précisions sur son fonctionnement, ses limites et ses conditions sont dans cette étude proposée par un pool de scientifiques dont la lecture demande un certain bagage technique.

La présente publication ne signifie pas que Framasoft promeut une quelconque application ni ne la présente comme une solution miracle. Il s’agit seulement d’éclairer le fonctionnement d’un protocole.

Bande dessinée originale en anglais : https://ncase.me/contact-tracing/

La traduction française que vous pouvez parcourir ci-dessous est due aux efforts conjugués et patients de Michel « Meï » Mancier, et de Samuel Hackwill. Qu’ils en soient vivement remerciés !