Quelques très bons sites et newsletters pour une veille culture numérique technocritique - édition 2025
12 mai 2025

Aujourd'hui plus que jamais, il est indispensable de s'informer, avec exigence, gourmandise et esprit critique (y compris pour penser contre soi-même). Et ce dans tous les domaines. En matière de culture numérique, voici ma sélection personnelle ET actualisée (La dernière édition datait de 2020) de sites, newsletters et podcast permettant de réaliser une veille culture numérique, avec un angle technocritique. Deux précisions importantes. D'abord, cette liste est non exhaustive et sans ordre logique. Ensuite, la plupart (mais pas tous) de ces contenus sont en accès libre, mais pensez à donner à leurs autrices et auteurs, car créer du contenu de qualité représente un énorme investissement en temps !

If you like this Kata, check out another Kata I’ve published using the example of an online car dealership: https://medium.com/nick-tune-tech-strategy-blog/architecture-ddd-kata-online-car-dealership-540c534121e2

If you would like to learn or practice how to break up a large business into domains and use them as the foundation for your software architecture and team organization, I have created a strategic domain-driven design kata that you may find useful. It’s based on the industry of online takeaway ordering and delivery using a fictitious business called Delivericious.

You can find the Miro board here: https://miro.com/app/board/o9J_l45tkpU=/

Je pense avoir un truc intéressant à dire en réponse à un commentaire de quelqu'un.
Je note l'URL de l'endroit ou se trouve le commentaire.

J'écris ma réponse à part.

Je le garde pour moi (dans mes notes).

Je reviens dessus plus tard (à froid) et je vérifie si c'est toujours pertinent.

Eventellement si je le trouve pertinent, je poste le commentaire.
Ou je le garde dans mes notes.
Ou j'écris un article.

Win win !

• J'ai extériorisé ce truc qui me donnait envie de réagir
• j'ai créé un raisonnement basé sur mon émotion
• mon émotion n'a pas impacté l'origine de celle-ci
• j'ai produit des idées peut-être utiles
• j'ai du contenu à publier

Podcast

by Felienne Hermans & Hanna Schraffenberger

The Computer Science Off Course podcast brings you one paper or book each week to widen your view on what Computer Science is, and what it could be.

Turing, Naur, Dreyfus, Laurel, and many more will bring some much-needed change in perspective for people who grew up on an information diet of only complex algorithms, programming, and math!

Read along with Felienne and Hanna, do the homework and see that there is more between heaven and earth than computers and compilers.

The past 3 years of work in NLP have been characterized by the development and deployment of ever larger language models, especially for English. BERT, its variants, GPT-2/3, and others, most recently Switch-C, have pushed the boundaries of the possible both through architectural innovations and through sheer size. Using these pretrained models and the methodology of fine-tuning them for specific tasks, researchers have extended the state of the art on a wide array of tasks as measured by leaderboards on specific benchmarks for English. In this paper, we take a step back and ask: How big is too big? What are the possible risks associated with this technology and what paths are available for mitigating those risks? We provide recommendations including weighing the environmental and financial costs first, investing resources into curating and carefully documenting datasets rather than ingesting everything on the web, carrying out pre-development exercises evaluating how the planned approach fits into research and development goals and supports stakeholder values, and encouraging research directions beyond ever larger language models.

Ma réaction à un commentaire (je ne l'ai pas publié).

@SirBenJamin_ 1 hour ago
In my experience, most coupling problems (and other architecture problems) are caused by teams where everyone works on all parts of the codebase, i.e people don't specialise in a particular area, they just pick up the next ticket on the backlog, and then even worse, other people who also have no experience in the area review the code. Managers will see this as a good thing, as they think they're getting more bang for their buck by 'spreading the knowledge.' ... but I really don't think it ever ends up like that, and the codebase suffers

I think "everyone works on all parts of the codebase" could not be a problem per se if the knowledge is evenly distributed. In very big systems it might not be possible and thus I agree with you that specialization could be an useful strategy. Also, you back this with your experience, so empirical evidence strenghtens your point.

In systems not so big, I think that T shape profile along with good ownership distribution (with pair programming, ensemble programming, ADRs), could also have positive effects on coupling problems. Meaning having knowledge a bit larger than hers scope could help having a glance of neigbourg culture (such as how mapping is done in the team next to me).

Techniques such as "swarming" : helping others being stuck or learning things outside of our initial scope (ex. QA, learning a bit of programming skill, Backend learning a bit of frontend ...) might help growing more shared mental models and thus slowly growing in the direction of full stack profile.

This lovely comic illustrates it pretty well I think : https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

Stratégie d'accessibilité un sujet que vous ne pourrez pas rattraper sans anticipation, la gestion hiérarchique des expertises. Traduction fiche du gouvernement anglais (#UK).

Dans le schéma pluriannuel d'accessibilité numérique, il y a une partie concernant la constitution des équipes (formations, promotions, embauches...). C'est une obligation légale d'annoncer la politique qui va permettre d'améliorer l'accessibilité.

Souvent, c'est : on a 2 personnes, on prévoit un stagiaire et un #UX ou un #Dev aura une petite formation. Pour un petit organisme, ça marche, mais pour un grand organisme, c'est bien plus complexe.

Si on pose les choses, on se rend compte qu'il faut faire des enquêtes estimer les compétences dans tous l'organisme, embaucher des experts, des auditeurs, former des spécialistes... combien d'#experts, #ambassadeurs pour X employés.

Il faut un référent expérimenté pour faire cela, une personne qui comprend tous les tenants et les aboutissants capable de mettre tout le monde à une place (estimation de l'expertise), prévoir des progressions, prévoir des reconversions, protéger/assister des profils.

Le référent accessibilité numérique va échafauder un plan (qu'il publiera dans le plan d'action) pour gérer les compétences pour le suivi qualité.

Dans le document ci-dessous (publier par GOV.UK), vous pouvez voir un aperçu des types de profils qu'ils ont déterminé et la manière dont ils les ont décrit.

Dans un grand #organisme ça pourrait constituer un plein temps. Alors que souvent il n'y a pas de référent, ou un seul référent peu expérimenté sur ce sujet.

Au delà des déclarations et schéma pluriannuel manquants ; vous pouvez donc essayer de comprendre le retard pris en France sur le sujet, c'est #abyssal.

(Sachant que ce n'est une fois ce plan stabilisé que vous pouvez intégrer concrètement la prise en compte de l'accessibilité dans un système #IA))

Car pour monter cela c'est d'abord du temps, mais aussi des #experts en interne. Et à force de ne pas prendre en compte l'accessibilité en France, des experts ++ en France, on en a presque pas.

Quand la DGCCRF - Ministère de l'Économie ou l'@arcom nous disent faire des contrôles, et progresser... c'est vrai je rigole. Les organismes français écopent le bateau à la petite cuillère.

#WCAG #RGAA #A11Y #Compliance #RH

Simon Bonaventure Frederic Halna A11y France