TOUTES LES REVUES
+
ACCÈS LIBRE

▸ les 20 dernières parutions

11.06.2025 à 16:48

FramIActu n°5 — La revue mensuelle sur l’actualité de l’IA

Framasoft
Alors que les chaleurs estivales arrivent, l'actualité de l'Intelligence Artificielle s'est elle aussi réchauffée ce dernier mois avec des avancées techniques majeures. Préparez votre boisson préférée et installez-vous confortablement : c'est l'heure de la FramIActu !

Texte intégral 4272 mots

Alors que les chaleurs estivales arrivent, l’actualité de l’Intelligence Artificielle s’est elle aussi réchauffée ce dernier mois avec des avancées techniques majeures.

Préparez votre boisson préférée et installez-vous confortablement : c’est l’heure de la FramIActu !

Le dessin d'un perroquet Ara, avec un remonteur mécanique dans son dos, comme pour les jouets ou les montres. Celui si est assis et semble parler.

Stokastik, la mascotte de FramamIA, faisant référence au perroquet stochastique. Illustration de David Revoy – Licence : CC-By 4.0

Pourquoi est-ce que Grok se met à parler de « génocide blanc » ?

Le 14 mai dernier, Grok, l’IA générative de xAI (société mère de X, ex-Twitter), a été détournée par un individu afin d’orienter les réponses de l’IA.
Celle-ci a, pendant plusieurs heures, parlé d’un génocide anti-blanc fictif qui aurait eu lieu en Afrique du Sud.
Outre le fait que l’événement ait surpris les utilisateurices de l’outil d’Elon Musk (patron de l’entreprise), celui-ci démontre qu’il est aujourd’hui possible d’orienter et d’influencer massivement les réponses des IA génératives.
Pour ce faire, la personne mal-intentionnée a exploité un outil fréquent des systèmes d’IA générative : le prompt système.

Plutôt que de ré-entraîner les IA génératives sur des éléments spécifiques ajoutés au fil de l’eau, les entreprises d’IA générative indiquent des instructions à l’Intelligence Artificielle au moment où l’utilisateurice fait sa propre demande. Cette instruction permet, par exemple, d’indiquer des règles de modération de contenu et de les adapter au fil de l’eau, en fonction des besoins.
Or, ces instructions ne sont pas communiquées publiquement. Nous ne savons jamais quand elles changent ni leur contenu exact.
C’est ce point qui a permis à l’attaquant·e de pouvoir modifier le prompt système discrètement.

xAI s’est engagé à publier les prompts systèmes sur la forge logicielle Github afin que tout le monde puisse consulter ceux-ci. Cela devrait aider à limiter une éventuelle récidive… même si rien ne peut le garantir.
Aussi, rien n’indique que la concurrence suivra ce mouvement et publiera aussi ses prompts systèmes.

Enfin, nous voyons encore une fois que les systèmes d’IA génératives sont plus complexes qu’ils n’y paraissent pour l’utilisateurice et manquent de transparence. Même si les prompts systèmes sont publiés, les données d’entraînement des IA génératives sont très opaques et nous manquons toujours énormément d’informations pour comprendre réellement ce qu’il se passe quand nous envoyons une instruction à une IA.

Est-ce que Google vient d’enterrer la recherche sur le web ?

Le 20 mai dernier, à l’occasion de la conférence Google I/O, Google a annoncé l’arrivée de nouvelles innovations biberonnées à l’Intelligence Artificielle.

Parmi celles-ci, vous avez peut-être déjà entendu parler de Veo 3, le nouveau générateur de vidéos ultra-réaliste de l’entreprise. Si, deux ans en arrière, nous pouvions nous moquer des images générées par IA, car nous pouvions facilement compter les 7 doigts présents sur les mains des personnes générées artificiellement, nous ne pouvons presque plus faire la différence entre un contenu réel et fictif aujourd’hui… et pas seulement pour les images mais pour les vidéos aussi.
Certain·es artistes s’amusent même à surfer sur la vague de popularité des vidéos générées par Veo 3 en indiquant que leurs propres clips vidéos, réalisés entièrement sans IA, seraient générés à l’aide de l’outil de Google.

Mais Veo 3 n’est pas la seule prouesse technique présentée par Google lors de l’événement. L’entreprise a dévoilé différentes nouveautés pour faire évoluer leur moteur de recherche et la manière dont les utilisateurices explorent (ou consomment) le Web.
Parmi les évolutions, et celle-ci est déjà accessible et utilisée par de nombreuses personnes, l’AI Overview, la fonctionnalité du moteur de recherche pour résumer l’essentiel d’un site web ou apporter une réponse à votre question… directement dans le moteur de recherche. Nous n’avons (ou n’aurons bientôt) plus besoin de sortir de Google pour obtenir réponse à nos questions.

Dans son article, Numerama rappelle :

Reste que Google n’a pas évoqué, encore, comment il compte rémunérer les contenus parcourus par son IA et répondre à la question que tout le monde se pose : à partir de quelles données l’IA répondra-t-elle quand aucun humain ne pourra être rémunéré pour les produire ?

Autre évolution importante et uniquement disponible aux états-unis pour le moment, les achats par IA.
Cette fonctionnalité nous permet de demander à l’IA de chiner pour nous sur les sites d’achats en fonction de critères choisis puis nous permet d’automatiser entièrement le processus d’achat via Google Pay.
Cette fonctionnalité, nommée « Buy for me » (« Achète pour moi » en français), permet de définir le prix auquel nous souhaitons acheter un article et le fera automatiquement dès que celui-ci sera trouvé.

Enfin, la dernière nouveauté rapportée dans l’article de Numerama n’est pas des moindres : celle-ci s’appelle sobrement AI Mode.
L’outil AI Mode permet, entre autres, de faire des « recherches profondes ».
Dans l’exemple présenté par Google, l’utilisateurice demande à l’
AI Mode de trouver deux billets pour un match de baseball avec des places situées vers le bas. L’outil essaye différents mots-clés pour sa recherche, puis compare 15 sites afin de trouver les places souhaitées. Les options trouvées sont alors triées du moins cher au plus cher avec une description de la vue obtenue sur le terrain à partir des sièges…

En quelques secondes, l’outil explore pour nous des dizaines de sites et en extrait les éléments qui pourraient nous intéresser. C’est (techniquement) absolument bluffant.
Pour réaliser toutes ces opérations, nous pouvons aujourd’hui imaginer
(bien que de manière extrêmement floue) la quantité d’énergie nécessaire à avoir la qualité de ces résultats de recherche.

Google détient ~90 % du marché mondial de la recherche en ligne. Cela représente 5 billions (5 000 000 000 000) de requêtes annuelles soit ~14 milliards de requêtes journalières.
Si Google décide de banaliser l’AI Mode et de l’intégrer directement dans son moteur de recherche, quelle quantité d’énergie sera nécessaire pour permettre ces 14 millions de requêtes ? Et même si grâce à cette nouvelle manière de rechercher celles-ci étaient réduites à (un chiffre totalement au pif) 5 millions de requêtes journalières, l’énergie requise semble rester totalement démesurée.

Aussi, nous en parlions dans une précédente FramIActu, mais le Web subit déjà aujourd’hui une pression monstre liée au « pillage » permanent de son contenu par les robots indexeurs des IA. Quels efforts les petits sites vont-ils encore devoir réaliser pour faire face à une augmentation drastique du trafic automatisé sur leur infrastructure ? Pourront-ils seulement y parvenir ?

Ici encore, nous observons un des mouvements récents de Google : le lancement d’une application mobile pour tester des modèles d’IA fonctionnant uniquement sur le téléphone de l’utilisateurice.

Si cela peut sembler anodin, il nous a semblé important de faire le lien avec la news citée plus haut.
Il paraît évident que Google a besoin de mettre en place des solutions pour réduire largement les coûts de l’inférence (en gros, le coût lié à l’utilisation de l’IA).

Un des moyens de réduire ces coûts est de déporter le travail de l’inférence vers la machine de l’utilisateurice, ici le smartphone.

Ainsi, en proposant une application permettant aux utilisateurices de tester les différents modèles d’IA, Google peut collecter de nombreuses données sur les capacités des smartphones actuels à faire tourner des modèles d’IA plus ou moins puissants.

Bien sûr, rien ne prouve que Google ira dans ce sens, cependant, il ne nous paraît pas totalement farfelu d’imaginer Google reproduire, dans un futur plus ou moins proche, une stratégie similaire à celle de Microsoft avec Windows 11 : forcer les utilisateurices à acheter du matériel neuf pour faire tourner l’IA dessus, accélérant de fait l’obsolescence des périphériques incompatibles.

Finalement, ces deux articles traitant des avancées de Google dans le domaine soulignent que Google tend à inverser le rapport de force avec OpenAI (l’entreprise derrière ChatGPT, la plus en vogue actuellement). Les futurs changements que Google apporteront seront sans doute déterminants dans l’évolution de nos usages.

Mème : un homme tagué « #LesGENS » regarde d'un œil intéressé une femme taguée « Google », pendant que sa compagne taguée « OpenAI » lui lance un regard noir.

Le rapport de force entre OpenAI et Google.
Généré avec https://framamemes.org – CC-0

OpenAI rachète l’entreprise de matériel de Jony Ivy

En mai dernier, nous apprenions que OpenAI a racheté l’entreprise io, spécialisée dans la conception de matériel informatique fondée par l’ancien designer en chef d’Apple, Jony Ive.
Ive ne rejoindra pas OpenAI et sa compagnie spécialisée dans le design, LoveFrom, restera indépendant, mais elle prendra désormais en charge l’ensemble de la conception des designs pour OpenAI, dont ses logiciels.

À travers l’article de The Verge, nous découvrons que le travail sur de nouveaux appareils, dédiés à l’IA, sont en phase de conception. Plusieurs pistes ont été considérées, comme des écouteurs ou des appareils disposant de caméras, mais ce ne sera pas des lunettes type Google Glass.
L’appareil rentrerait dans une poche, « tiendrait compte du contexte » et ne posséderait pas d’écran.

Nous nous questionnons particulièrement sur la notion de « tenir compte du contexte ». Qu’est-ce que cela signifiera concrètement ? Serait-ce encore un dispositif qui « écoutera » ou « observera » en permanence, sous prétexte de pouvoir nous répondre immédiatement quel temps il fera demain quand nous poserons la question à nos proches ?
Pour le moment, nous n’en savons trop rien.

Il est difficile de dire si le pari (à 6.5 milliards de dollars, tout de même) de OpenAI portera ses fruits, cependant, si OpenAI affirme que l’objectif n’est pas de remplacer le smartphone, il semble y avoir une réelle volonté à suivre la piste de celui-ci : construire un appareil ergonomique qui s’impose comme un nouveau besoin pour la société. Et dans le même temps, imposer toujours plus l’IA dans nos quotidiens.

Le dessin d'un perroquet Ara, avec un remonteur mécanique dans son dos, comme pour les jouets ou les montres. Accroché à son aile gauche, un ballon de baudruche.

Stokastik, la mascotte de FramamIA, faisant référence au perroquet stochastique. Illustration de David Revoy – Licence : CC-By 4.0

C’est tout pour cette FramIActu ! Nous espérons que vous l’avez appréciée !

Vous pouvez poursuivre votre lecture sur le sujet en consultant les articles de notre site de curation dédié au sujet, mais aussi et surtout FramamIA, notre site partageant des clés de compréhension sur l’IA !

Si nous pouvons vous proposer cette nouvelle revue mensuelle, c’est grâce à vos dons, Framasoft vivant presque exclusivement grâce à eux !
Pour nous soutenir et si vous en avez les moyens, vous pouvez nous faire un don via le formulaire dédié  !

Enfin, notez que le rythme de parution de la FramIActu risque de changer dans les prochains mois. Nous constatons en effet une diminution du rythme de parutions d’informations « intéressante pour le grand public » sur l’IA. Il y a certes des avancées techniques, et toujours énormément de recherches sur le sujet… mais nous percevons tout de même une forme de baisse de régime. Attendez-vous donc à d’éventuels changements autour de la FramIActu pour refléter tout ça !

À bientôt ! 👋

11.06.2025 à 12:10

Développement d’application en Flutter : retours d’expérience (1/2)

Framasoft
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 … Lire la suite­­

Texte intégral 3063 mots

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.

Logo Flutter – Domaine public – Wikicommons.

 

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 :

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 !

09.06.2025 à 07:42

Khrys’presso du lundi 9 juin 2025

Khrys
Comme chaque lundi, un coup d’œil dans le rétroviseur pour découvrir les informations que vous avez peut-être ratées la semaine dernière. Tous les liens listés ci-dessous sont a priori accessibles librement. Si ce n’est pas le cas, pensez à activer … Lire la suite­­

11048 mots

Comme chaque lundi, un coup d’œil dans le rétroviseur pour découvrir les informations que vous avez peut-être ratées la semaine dernière.


Tous les liens listés ci-dessous sont a priori accessibles librement. Si ce n’est pas le cas, pensez à activer votre bloqueur de javascript favori ou à passer en “mode lecture” (Firefox) ;-)

Brave New World

L’info popcorn de la semaine

Spécial IA

Spécial Palestine et Israël

Spécial femmes dans le monde

Spécial France

Spécial femmes en France

RIP

Spécial médias et pouvoir

Spécial emmerdeurs irresponsables gérant comme des pieds (et à la néolibérale)

Spécial recul des droits et libertés, violences policières, montée de l’extrême-droite…

Spécial résistances

Spécial outils de résistance

Spécial GAFAM et cie

Les autres lectures de la semaine

Les rapports de la semaine

Les BDs/graphiques/photos de la semaine

Les vidéos/podcasts de la semaine

Les trucs chouettes de la semaine

Retrouvez les revues de web précédentes dans la catégorie Libre Veille du Framablog.

Les articles, commentaires et autres images qui composent ces « Khrys’presso » n’engagent que moi (Khrys).

12 / 20