🇺🇸 – Last update: Monday, January, 12th 2026

Keywords: #Swift, #SwiftUI, #iOS, #iOSDev, #Apple

Here are some summaries of main news about SwiftUI, just to keep them in mind and list (more detailed) sources. A lof of this content is written thanks to the awesome work of Hacking with Swift. If you consider supporting this publication, prefer supporting them instead.

You can find Xcode details here, and also Swift details API here.

iOS 26 / Xcode 26.0 / Swift 6.2 (2025)

WebView can be populated by remote sites (and also local HTML) with WebKit update.

Rich text editing is available with AttributedString as bding to let users write text with weights etc.

SF Symbols got animations to draw themselves

And also other improvements with TabView and components for Liquid Glass

Sources

• hackingwithswift.com (WebView)
• hackingwithswift.com (rich text)
• hackingwithswift.com (SF Symbols)
• hackingwithswift.com

iOS 18 / Xcode 16.0 / Swift 6.0 (2024)

View on main actor, thus not needed anymore to add @MainActor on views protocols properties.

PresentationSizing protocol helps to create our own sizes for views.

onGeometryChange() modifier lets us track when a view's frame, size or safe area insets change, and also onScrollGeometryChange() for ScrollView.

TabView has now dedicated Tab children, but it could bring failures for old code on iPadOS.

Accessiblity label and hint have modifiers to define them as views.

Tab bar can be floating

Sources

• hackingwithswift.com (PresentationSizing)
• hackingwithswift.com (onGeometryChange)
• hackingwithswift.com

iOS 17 / Xcode 15.0 / Swift 5.9 (2023)

Scroll view has been improved.

Drawing and animations have been improved, and SF Symbols can be animated easily.

In-app purchases can be displayed easily and in simple fashion with SwiftUI thanks to dedicated views ready to be used.

sensoryFeedback() is available for haptics.

ContentUnavailableView is here to tell the user that no content is available.

Sources

• hackingwithswift.com (in-app purchases)
• hackingwithswift.com (sensoryFeedback)
• hackingwithswift.com (ContentUnavailableView)
• hackingwithswift.com

iOS 16 / Xcode 14.0 / Swift 5.7 (2022)

Bottom sheet presentation has been improved with presentationDetents() view modifier.

Tap location on view is easier to get.

ShareLink view makes it easy to share any kind of data from the app as long as it conforms to the Transferable protocol.

requestReview (StoreKit) allows users to rate the app.

PasteButton can be used to let the user paste data into the app if Transferable.

NavigationStack is here! With this new view we can for example implement more easily some navigation patterns like router pattern so as to have the navigation less stucked to the UI.

LocalizedStringResource is also available. It will ease the use of resources needed to be localized in a more general and abstract way than the LocalizedStringKey. This is interesting when the type inference fails to parse some strings as working keys.

Sources

• hackingwithswift.com (ShareLink)
• hackingwithswift.com (requestReview)
• hackingwithswift.com (PasteButton)
• hackingwithswift.com

iOS 15 / Xcode 13.0 / Swift 5.5 (2021)

refreshable() brings pull-to-refresh behaviour for lists!

searchable() brings search bar to filter data!

swipeActions() for list row are a reality!

AsyncImage view can load remote image from a URL!

Toolbar can be added to the keyboard.

task() let run asynchronous task when a view is shown.

Sources

• hackingwithswift.com (pull to refresh)
• hackingwithswift.com (search filter)
• hackingwithswift.com (swipe actions)
• hackingwithswift.com (AsyncImage)
• hackingwithswift.com (task)
• hackingwithswift.com

iOS 14 / Xcode 12.0 / Swift 5.3 (2020)

@StateObject is available to create a reference type inside one of our views and make sure it stays alive for use in that view and others (like children views). Usefull for example for view models we fear to loose or have destroyed somewhere somehow.

Sources

• hackingwithswift.com (@StateObject)
• hackingwithswift.com

iOS 13 / Xcode 11.0 / Swift 5.1 (2019)

Don't fu****g use SwiftUI with iOS 13. It's a nightmare. A hell of bugs, performances issues and glitches.

Sources

Me and my tears.

— Posted on Monday, May 12th 2025 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇺🇸 – Last update: Wednesday, January, 14th 2026

Keywords: #Swift, #Swiftlang, #iOS, #iOSDev, #Apple

Here are some summaries of main news about Swift, just to keep them in mind and list (more detailed) sources. A lof of this content is written thanks to the awesome work of Hacking with Swift. If you consider supporting this publication, prefer supporting them instead.

You can find Xcode details here, and also SwiftUI details here.

Swift 6.2 / Xcode 26 (2025)

Control default actor isolation inference with default-isolation MainActor flag to move to single-thread paradigm (SE-0466).

Raw identifiers range updated with more symbols to use for naming (SE-0451)!

Default value for string interpolation making debug and strings processing a bit smoother (SE-0477).

Collections can be enumerated, finaly (SE-0459)!

Method and initializer key paths, to manipulate, store, call and use functions in another way (SE-0479).

unsafe keyword to use whe strict memory safety is enabled and code marked @unsafe (SE-0458).

Backtrace API to ease functions debuging with call stacks (SE-0419).

weak let comes finaly to improve weak var (SE-0481)

Transactional observation of values with a new Observations struct which provides an AsyncSequence that emits new values whenever any @Observable data changes (SE-0475).

Global-actor isolated conformances making it possible to restrict a protocol conformance to a specific global actor (SE-0470).

Starting tasks synchronously from caller context, i.e. create Task to run immediately (SE-0472).

Run nonisolated async functions on the caller's actor by default except if @concurrent is used (SE-0461).

Isolated synchronous deinit to be able to call deinit isolted to actors (SE-0371).

withTaskPriorityEscalationHandler for task priority escalation (SE-0462).

Now tasks can have names to ease debugging for example (SE-0469).

Fixed-size array with InlineArray, a mutable array but with fixed size (SE-0453).

And also improvements for regex with symbols assertions (SE-0448), expect(processExitsWith:) with Swift Testing (ST-0008), attachments for tests with Swift testing (ST-0009) and condition traits for tests (ST-0010), non-escapable types (SE-0446), yielding accessors (mutate, borrow) (SE-0474), and more things.

Sources

• swift.org/blog
• hackingwithswift

Swift 6.1 / Xcode 16.3 (2025)

Concurrency has been updated. Now the nonisolated keyword, used to indicate that an API is safe to call from any concurrent context, can be used for types and extensions ; it prevents for example to add the keyword for every properties or methods in extensions.

Trailing comas can be added at the end of tuples, argument lists and string interpolations for example ; not only in collection literals.

Package traits can now be defined inside Package.swift definitions so as to define configurations for specific environments like WASM.

Swift Testing has been improved with custom traits to perform logic before or after tests (e.g. for set-up and tear-down actions). Test scopes can be customized, for example for mocks usages. #expect(throws:) and #require(throws:) have been improved also.

Swift-DocC provides better management of references of methods with same signatures.

Sources

• swift.org/blog
• ST-0007 (GitHub)

Swift 6 / Xcode 16.0 (2024)

Concurrency comes! Now, if enabled, we can use the power of concurrency and its new API to ensure the source code is thread-safe with improved memory safety and no more data races.

Typed throws are now available. Methods in their signatures can define which types of errors are thrown, and it brings better clarity and consistancy.

Ownership provided with Swift 5.9 has a bit been improved and can be applied to generics.

C++ interoperability has been improved with support of move-only types, virtual methods, default arguments and also more standard library type.

Embedded Swift is included as preview with Swift 6 ; this toolchain supports ARM and RISC-V.

128-bit integers are now managed in their signed and unsigned variants.

@DebugDescription is now available for custom LLDB summaries ; this new macro let specify LLDB type summaries for our own types in the code to ease debugging.

Foundation has been refactored with some API converted to Swift like JSONDecoder, URL, Calendar, FileManager, ProcessInfo, FormatStyle, ParseStrategy, Predicate, JSON5.

Swift Testing exists! Expressive API, more simple to use compared to XCTest, scales large codebases with features like parameterization.

Sources

• swift.org/blog
• swift.org/migration
• github.com/swift-testing

Swift 5.9 / Xcode 15.0 (2023)

Macros can be used to reduce repetitive boilerplate and work just like built-in language features. They are based on SwiftSyntax.

Parameter packs with generics syntax allow to define one method signature with an undefined list of parameters, without upper limits, even for returned values.

Ownership is featured. The new consume operator tells Swift to deinitialize a variable and transfer its contents without copying it. The borrow operator comes too, and structs and enums can be defined as noncopyable. The discard keyword is also here for consuming methods of elements having a deinit to bypass.

Syntax has been improved with the if and switch more modernized in their available syntaxes.

Sources

• swift.org/blog
• ST-0377 (GitHub)
• ST-0390 (GitHub)
• ST-0380 (GitHub)
• gayeugur.medium.com
• github.com/swiftlang/swift-syntax
• hackingwithswift.com

Swift 5.8 / Xcode 14.3 (2023)

It prepares for the Swift 6 big changes and its upcoming features. Developer experience has been improved.

@backDeployed is available and makes possible to allow new API to be used in older versions of frameworks by writing code for a function into app's binary then performing a runtime check.

implicit self for weak self captures is a reality and makes for example guard let else syntax smoother.

It is also possible to have functions with generic parameter which can be optional on the parameter definition.

Collection downcasts in cast patterns are supported and can be useful for example with switch case let as pattern.

Resources

• swift.org/blog
• hackingwithswift.com

Swift 5.7 / Xcode 14.0 (2022)

if let for unwrapping optionals is now shorter.

Regex has been enriched a lot with DSL for example.

Opaque parameter declarations and result types can be managed with the use of some keyword in parameter declarations.

Sources

• swift.org/blog
• hackingwithswift.com

Swift 5.6 / Xcode 13.3 (2022)

any keyword is available to mark existential types, which is different than opaque types with some keyword. The any keyword is here to bring optimization when objects are used through their abstract types making the runtime use the dynamic dispatch process for optimization. Thus this process won't be used.

Type placeholder with _ symbol can be called to let the compiler define types of variables (in, for example, declarations).

Concurrency has been enriched to prepare Swift 6 with the @preconcurrency macro and other improvements with @Sendable and @MainActor.

Sources

• swift.org/blog
• hackingwithswift.com

Swift 5.5 / Xcode 13.0 (2021)

async/await and async/throws are now real! Here come asynchronous functions, allowing to run complex asynchronous code without for example needing to use in some cases Combine. Task is also shipped.

AsyncSequence come with async/await also.

Actors are also embedded, i.e. kind of classes that are safe to use in concurrent environments with their content accessible by a single thread at any given time.

Sendable are here to define if data can safely be transferred to another thread.

lazy has been improved to be used in local contexts and write stored properties only calculated when first used ; interesting for heavy objects.

Sources

• swift.org/blog
• hackingwithswift.com

— Posted on Monday, May 12th 2025 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇫🇷 – Mercredi 30 octobre 2024

Mots clés: #web, #internet, #navigateur, #ViePrivée, #merdification

Le web a été totalement travesti ces dernières années, voire décennies. De plus en plus de merdification, de monopoles, de silotages et de nivellement par le bas. Quand j'étais gamin, je voyais le web – au sens large – comme quelque chose d'universel. J'ai écrit mes premières lignes de code pour des pages web via le Site du Zéro. Je me rends compte qu'en l'état actuel des choses, cette universalité est une supercherie, une fumisterie grotesque. Ce billet de blog a un gros côté “Team Vieux Cons”, je préviens.

Comment c'était "avant" ?

Apparemment il y a des gens qui aiment en mettre d'autres dans des cases, et je serais alors un millennial, un digital native ou un spécimen de la génération Y, en gros je suis né au début des années 1990. De fait, on ne parlait pas encore de “fracture numérique”, l'informatique domestique n'était pas encore démocratisée (pas autant qu'aujourd'hui), et quand on habitait en zone rurale l'ADSL n'était pas encore mis en place, on avait droit à des débits de 56kb/s au mieux avant qu'il n'arrive avec sa vingtaine de Mb/s. Bref, je n'ai pas connu la naissance de l'informatique, ni celle du web, je ne prétends pas la connaître non plus, mais j'ai vu les choses s'installer tranquillement.

Avant, du côté des navigateurs web, il y avait Netscape, Internet Explorer, et d'autres trucs aussi que je n'ai pas connus. Puis Opera, Firefox et Safari. Chrome ne sera arrivé que bien plus tard vers 2008. Edge n'existait pas, ni Brave, et on ne parlait pas de Chromium.

Les pages HTML étaient simples. Moches selon les critères de nos jours, mais se composaient de XHTML et de CSS ; le HTML 5 et le CSS 3 de mémoire étaient arrivés dans les années 2010. Par contre, effectivement, pour certaines choses comme l'audio et la vidéo, on avait du Silverlight et du Flash. En dehors de ça, on savait faire simple. On était obligés de faire simple. Les débits, toujours selon les critères de nos jours, étaient médiocres. Les ordinateurs parfois n'avaient pas plus de 2 ou 3 Go de RAM (et bien moins avant). Les pages HTML devaient être légères car sinon mettaient trop de temps à être chargées, et les dépassements de forfaits étaient très vite lourdement facturés. Pas de DRM, pas ou très peu de JavaScript (qu'on désactivait à l'époque pour gagner du temps tout comme l'affichage des images), pas ou peu de publicité (mais vite arrivée en force ensuite), pas de tracking. Bref, du web documentaire que l'on pouvait considérer d'une certaine façon comme épuré, voire pur. Et plus tard, quand on voulait commencer à faire des pages “réactives”, avec quelques requêtes, on faisait du AJAX. Du JavaScript asynchrone, qui consommait du XML ou plus tard du JSON, et ce, au travers de XMLHttpRequest. On se contentait aussi des faire des requêtes de formulaires simples, allant taper directement le serveur qui nous renvoyait ensuite tout ou partie de la page visité.

Les premières bibliothèques comme MooTools ou jQuery ont commencé à venir, et le merdier aussi.

Les technologies de développement

On a oublié de faire simple. Et on a cherché à tordre le HTML et le CSS dans tous les sens, à totalement travestir le truc. On est limité, cloitré au navigateur web, mais on va chercher à faire des sites web de plus en plus complexes, et même des Progressive Web Apps.

Le JavaScript est devenu incontournable et indispensable, quand bien même ce langage de programmation est exécrable et trop permissif. Alors certains diront que l'on a TypeScript aussi, mais ça reste finalement la même merde qui sera générée / transpilée et exploitée par la suite. On a juste changé l'emballage.

On avait MooTools. Puis jQuery. On avait même des applets Java. Et ensuite AngularJS. Puis Angular. Polymer aussi, qui aussi a rejoint AngularJS dans le Google graveyard, et Bootstrap. Et enfin ReactJS qui n'est plus maintenu au profit de React. Et on a même Flutter qui s'y met. Certes, je mélange les torchons sales et les serviettes trouées, mais quand même. Le but est le même : faire des pages web affichées par son navigateur web. Mais on a voulu faire des ensembles de pages, qu'on appelle “sites”. Et on a voulu ajouter d'autres logiques dedans et parodier ou plagier gauchement les applications mobiles, en appelant ça “applis web”. Les pages sont de plus en plus complexes. Le DOM, que l'on pouvait facilement fouiller avant, finalement est remplacé par le shadow DOM de plus en plus pénible à investiguer. On va avoir des évènements JavaScript en pagaille, avec des chargements de pages ici ou là, partiels ou non, et une tonne de fichiers JS que l'on va tirer depuis les pages via des CDN, sans même forcément s'assurer qu'ils n'aient pas été compromis. Des requêtes réseaux en pagaille pour aller chercher des ressources devenues indispensables pour faire fonctionner des foutues pages web totalement travesties.

Avant, si on voulait travailler sur un projet web, ou a minima bricoler un truc, on s'en sortait très bien avec les bases du HTML et du CSS, voire du JavaScript. Maintenant, si on ne connait pas la dernière stack à la mode, qui en plus va utiliser des préprocesseurs ou extensions CSS comme Sass ou Less, et le dernier framework du moment comme Vue.js ou Svelte ou un langage de programmation tout nouveau portée par la hype comme Elm, on ne s'en sort plus. Les technologies web d’aujourd’hui sont déjà du code legacy, pas besoin d'attendre demain pour les voir dépréciées et vite remplacées. Tout le monde lave plus blanc que blanc, mais au fond ça reste le trio HTML + CSS + JS. Ça reste de la merde, seule la couleur change, pas l'odeur.

Pire encore, on augmente les surfaces d'attaque et les probabilités d'avoir des problèmes en dépendant d'outils desquels on est devenu trop dépendant. Il a fallu un bad buzz pour que Facebook remplace la licence BSD+Patent de React pour passer à MIT. Avec Web Assembly on va injecter du code binaire dans les projets web, faisant que l'on pourra encore plus difficilement savoir ce qu'il s'y passe. Si on prend des outils clés en main comme WordPress, on se prend souvent des alertes à cause de plugins ayant des failles de sécurité, sans parler du psychodrame actuel entre le fondateur de WordPress et WP Engine. Idem pour les usines à gaz que sont les CMS comme Drupal et PrestaShop avec de temps en temps des alertes critiques. On avait même polyfill.js qui avait été compromis.

Et côté backend et au delà c'est pas glorieux. Node.js avec son API standard incapable nécessitant pléthore de dépendances tierces plus à jour, sabotées ou sujettes à des failles de sécurité, J2EE, Ruby on Rails, PHP et son PreHistoric Programming, Symfony, Laravel, Django, ASP.net, ... On a une tétrachiée d'outils pour faire du backend et plus encore, et qui font plus ou moins la même chose. Et certains organismes de formation sans scrupules iront former des jeunes ou des personnes en reconversion à l'arrache, vider leurs porte-monnaies, les formant sans sérieux, et les balancer sur le marché du travail dans des marchés saturés.

Certains ont tenté de faire des applications mobiles web avec un OS dédié, comme Firefox OS, mais le projet a capoté. Peut-être pas pour un mal.

Si je prends une échelle de temps relative, forcément plus courte mais tout de même, du côté du développement d'applications mobiles (natives j'entends, les seules qui vaillent évidement), on a eu moins de changements et de risques de se créer de la dette technique. Du côté du développement d'apps Android, on est juste passé de Java à Kotlin, progressivement. Et Java a été officiellement destitué que tout récemment. Même chose pour iOS, on est passé de Objective-C à Swift, mais en soit, l'ancien langage de programmation n'est pas déprécié pour autant. On garde UIKit et SwiftUI pour la définition des interfaces graphiques, rien de déprécié là aussi. Un peu moins vrai pour Android avec Jetpack Compose qui remplace les layouts XML. Bref, bien moins de changements structurants, de dettes techniques et d'outils dépréciés, car les choses sont davantage normalisées et lisibles. On n'a pas plusieurs crémeries qui vont tenter de vendre leur beurre en tentant de planter les autres. Pour l'embarqué, ça bouge encore moins. On a Qt, et c'est assez. Finalement personne n'a besoin d'un énième framework qui refasse ce que les autres font, mais différemment. Les tendances finiront par arriver, mais tranquillement et proprement. Bref, c'est moins le foutoir.

La merdification systématique

Je n'ai pas l'impression que le web ait beaucoup d'innovations qui vont dans le bon sens, à savoir celui du progrès plutôt que celui des intérêts privés et capitalistes. Si on regarde Web Assembly, il y a de l'idée. Avoir un code source quelconque, en tirer un binaire, et balancer ça sur les navigateurs, ok. Toutefois, comment contrôler ce qu'il s'y passe ? Comment s'assurer de la loyauté de ce binaire ? On apporte de l'opacité à un environnement qui, avant, laissait l'utilisateur le bidouiller, fouiner dedans, et voir comment les choses étaient foutues. Même chose pour le JavaScript, on en vient à intégrer sur les pages web du code propriétaire, opaque, privateur, qui est là pour surveiller, pister ou forger des empreintes numériques permettant de traquer l'utilisateur peu importe où il va. Quand on parle de logiciels, on arrive vite à la dichotomie entre les logiciels libres (au sens donné par la Free Software Foundation, le seul qui vaille) et les logiciels propriétaires. Or, on oublie vite que c'est le même problème pour le code JavaScript qu'on subit lorsque l'on surfe sur le web. Le code JavaScript est un piège, vite déloyal, vite dangereux.

Avant, modulo des animations clignotantes et des GIF horribles, les pages étaient simples. Le contenu était rapidement accessible. Maintenant, c'est une purge. On se prend déjà un bandeau pour accepter les cookies, contraignant à tous les accepter ou passer par un parcours insupportable pour choisir ceux que l'on ne veut pas, en supposant que ces choix soient respectés. À cela s'ajoutent les panneaux publicitaires, proposant tout et n'importe quoi. Et ensuite un paywall, soit en cours de lecture pour appâter l’utilisateur, soit dès l'affichage de la page pour forcer l’utilisateur à accepter tous les cookies (donc le pistage) ou à prendre un abonnement. Les champions sont les sites de presse en ligne que l'on doit plaindre si on les écoutait ; ils ont choisi délibérément de se lier pieds et poings chez Google ou Facebook, mais dès que certains comme Apple et la “gomme magique” de Safari arrivent pour dégager leurs merdes, ils se plaignent. Ils sont nés avant la honte.

Des justifications merdeuses

En discutant avec les gens au sujet du web et des technologies de développement “web”, j'entends toujours les mêmes arguments éculés.

Les DRM permettent de fournir une meilleure expérience à l'utilisateur. Non. Déjà car ici on pense surtout à des consommateurs. Et ensuite parce que ces Digital Rights Management sont des cancers pour le web libre. Zoner géographiquement, empêcher l'accès, la copie, la diffusion, c'est purement de la censure à des fins mercantiles. À quel moment on a cru bon d'accepter ces verrous numériques pour le web ?

Les technos web réduisent les coûts de développement. Si un choix technique ou technologique est justifié par un argument financier, ce choix est par définition mauvais. Les logiciels faits grâce à (ou à cause de) Electron sont les pires que je n'ai jamais pu utiliser, en terme de performances ou d'efficacité. Idem pour les machins à base de PhoneGap, Ionic ou Cordova. Même la suite Teams de Microsoft passant de Electron à WebView2 est une purge à utiliser. Ça bouffe de la RAM, ça glitch, ça refresh mal, l'accessibilité est dégueulasse, ça ne reprend pas les codes plus sains des logiciels natifs.

Ça donne une expérience unifiée pour l'utilisateur. Non. Embarquer des web views dans des applications mobiles est une connerie. On augmente la surface d'attaque, on consomme davantage de bande passante, on se retrouve avec des failles de sécurité en plus tant dans le code web qu'à cause du navigateur faisant le rendu, l’accessibilité est souvent foirée, et on se retrouve parfois avec des régressions identifiées tardivement à cause d'effets de bords indésirés. On modifie la page web pour changer une fonctionnalité, sauf que c'est tracé nulle part côté application et l’utilisateur ne se rend compte de rien. Sans oublier qu'on zappe parfois la mise en cache des données et le mode hors-ligne. Les web views sont un excellent moyen de déposséder l'utilisateur ; suffit de ne pas faire de cache et de changer la page ou la rediriger, et c'est terminé.

Le HTTPS permet d'être sécurisé. Oui, c'est vrai. Mais pour du contenu statique on n'en a pas besoin du tout. À cause du tout HTTPS, on se retrouve avec par exemple des ordinateurs “vieux”, avec des “vieux” navigateurs web, qui n'ont plus leurs certificats à jour. Donc un “vieux” iMac, qui fonctionne bien mais plus mis à jour depuis quelques années toutefois, ne pourra plus permettre à l'utilisateur de naviguer sur les internets car on aura du HTTPS partout et le navigateur web ne pourra afficher le contenu à cause de certificats révoqués ou obsolètes. TLS 1.0 et 1.1 sont obsolètes depuis 2018, donc des certificats racines ne sont plus mis à jour, donc des sites web inaccessibles. Bingo.

C'est nouveau, c'est génial. J'ai entendu ça sur le server-side rendering (SSR), un cran plus loin dans la merdification. On a des gens qui sont satisfaits d'avoir réinventé la roue : le serveur web qui va construire la vue HTML. Retour aux débuts du web. On avait le serveur qui renvoyait la page à afficher, puis on a fait des API SOAP, puis on a fait des API REST, puis des API GraphQL, et là on fait ce SSR. Et des pignoufs vendent ça comme de l'innovation, quels escrocs. Faire du développement web c'est faire de la hype driven development.

Des pétards mouillés aussi

Qui a encore entendu parler du physical web ? Ces pages et sites web qui arrivent sur nos appareils grâce à des beacons qui diffusent des signaux, notamment près des bornes publicitaires ? Un gag.

Et les progressive web apps (PWA) alors ? Un plagiat ridicule des applications mobiles. Les utilisateurs ne comprennent pas comment les installer, ce n'est pas naturel. On est toujours limité de près ou de loin par le navigateur. Ça impose d'avoir du JavaScript pour gérer la mise en cache avec le service worker. Qui, lui, impose d'être en HTTPS pour fonctionner. On pourrait s'attendre à avoir des vraies évolutions, comme des threads ? Les web workers n'y arrivent pas sérieusement. Sans compter qu'encore aujourd’hui des API accessibles par les apps mobiles ne le sont pas par les PWA, et que par essence et par définition les apps mobiles natives seront toujours en avance sur l'usage des terminaux contrairement aux PWA qui n'innoveront jamais et persisteront à corriger le retard.

Et les neutralités du net et du web ?

Un lointain souvenir. Les adresses IP des VPN sont de plus en plus sur listes noires. Si on utilise des bloqueurs de pubs les sites sont inutilisables, soit délibérément, soit par conception maladroite. Il y a de plus en plus de discrimination envers les usagers, sans parler des problématiques réseaux. Le simple fait de vouloir utiliser TOR nous prive d'une bonne part du web. Sans parler du fait que de plus en plus de sites web ne fonctionnent pas bien voire refusent de fonctionner selon les navigateurs. Ou alors vous imposeront des contrôles “anti robots” et des captchas, notamment si le site est géré par au hasard Cloudfare. Franchement, j'en ai marre de résoudre des puzzles et d'attendre qu'un système obscur me donnent l'accès à un site web. Parfois même les sessions sont suspendues car on est considéré comme autre chose qu'un humain légitime. Désolé bande de clowns, j'ai un logiciel qui bloque la publicité, le code JavaScript déloyal et qui me fait sortir ailleurs qu'en France, juste pour protéger ma vie privée. Et c'est justement à cause de vous si j'en suis là. Escrocs.

Un noyautage public

Et pendant ce temps, on remarque que Google et consorts continuent leur noyautage du web et de ces instances, ainsi que le silotage de tout ça. Les DRM sont validés par le W3C, Chromium prend presque toutes les parts de marché et applique la stratégie 3E : maintenant que la place est prise, on se débarrasse de ce qui est nuisible, comme par exemple uBlock Origin. De plus en plus de sites web se plient au règles de Google en terme de SEO. Google est en train de foutre en l'air le web ouvert et libre, et ce, délibérément avec son projet de web environement integrity. On peut aussi parler du Manifest v3 de Google encadrant les extensions des navigateurs, toujours pour favoriser les pisteurs et privilégier ce qui intéresse les géants du numérique en torpillant les projets qui préfèrent protéger les utilisateurs. Ou encore des tentatives pour dégager des formats ouverts, notamment de la part de Google avec JPEG-XL.

Le web social, boulimique, grotesque et égocentrique

Le web 2.0, le web social, a amené les gens à s'exprimer plus facilement, à créer du contenu, à en partager. Forcément les gros datavores comme Facebook maintenant Meta mais aussi X anciennement Twitter, ou encore Reddit et j'en passe, se sont rués dessus. On incite les gens à créer, commenter, liker, partager. On engloutit autant de données personnelles que l'on peut, soit en exploitant les contenus, soit leurs métadonnées. Et ensuite on se gave encore sur ça en créant de gros corpora de données pour entrainer des modèles d'intelligence artificielle. Et on verrouille aussi les API, faisant qu'un paquet d'applications qui pouvaient interagir avec Twitter ou Reddit ont plié boutique.

L'effet pervers de ce web social est qu'il a fait naître les influvoleurs et instabouffons, dit autrement les influenceurs et dindons de tous poils qui commentent, donnent leurs avis, lustrent leurs communautés de blaireaux avec des hot takes claquées au sol ou en vendant des produits bidons. Même dans les milieux de la tech on en a, surtout dans le monde du développement web. Des paons et des dindons, formant des communautés de pigeons, gavés d'articles LinkedIn mauvais, de vidéos YouTube médiocres, enfonçant des portes ouvertes et rendant le banal et classique tout simplement incroyable. Et quand on les met en face de leurs impostures, ils lâchent leurs chiens sans sommation pour protéger leur crédibilité fantoche. Ces gens là sont responsables de rendre les autres plus cons qu'avant, et de leur faire croire à des rêves idiots. Regardez, c'est facile de coder, waouh je fais des choses trop bien, vous allez être développeurs grâce à ma formation. Résultat ? Trop de personnes s'étant reconverties avec des formations minables, sans culture, sans bagage sérieux, saturant les marchés.

Je pensais que la communauté Debian était une des pires, avec sa mentalité RTFM. Mais une communauté web la surclasse, celle qui adore le JavaScript et le web front ; constamment soumise à la hype, à réinventer la roue, à s'extasier devant des choses basiques ou peu originales, et à avoir l'arrogance de croire que le web va tout surclasser. Pire encore, une partie des membres de cette communauté va se former à l'arrache, et se croire meilleure. Heureusement, comme partout, il y a les bons et les mauvais artisans du logiciel, et j'ai de chouettes collègues qui font du développement web, mais bon sang, je n'ai jamais vu autant de kikoos et de crétins dans le développement web front end. On peut trop rapidement et trop facilement faire des choses, et surtout n'importe quoi et n'importe comment. Les mêmes nous font croire qu'il n'y a pas de problème à parler de front end quand on parle d'apps Android et iOS ; ils n'ont jamais touché à cet art pour comprendre à quel point ce propos est réducteur. Et de temps en temps, les mêmes, toujours, tentent de se tailler la part du lion en poussant leurs technologies à eux. PhoneGap, Cordova, Ionic, maintenant React. Autant de dette technique en puissance, voire en acte, et de dépendance à des outils que l'on ne maîtrise pas, sans parler du fait que ni Google d'un côté pour Android, ni Apple pour iOS, ni mêmes d'autres acteurs comme /e/ ne recommendent, à l'heure où j'écris ce lignes, de passer par ces outils tiers. Bref, que les clowns du développement web front end s'occupent déjà de faire des pages HTML propres et arrêtent d'entretenir les porcs comme Google et tous ceux qui ont travesti le web et se gavent dessus. Ils pourront donner des leçons et polluer le développement d'apps mobiles une fois que leur maison aura cessé de brûler. On n'a pas besoin qu'ils fassent les pompiers, juste que les flammes ne se propagent pas de chez eux à chez nous. Est-ce du gatekeeping ? Probablement, mais on en arrive là pour éviter le nivellement par le bas et l’uniformisation ridicules des environnements.

Le web social a permis le partage de la connaissance, il a aussi aidé à la fabrique du mensonge. On partageait aux autres avant, on s'étale aux yeux du monde maintenant.

On pensait même être tranquille avec le fediverse comme dans les écosystèmes Mastodon ou Pixelfed, mais on trouve encore des géants du numérique comme Meta qui tentent de mettre un pied dans la porte afin de récupérer toujours plus de données avec Threads par exemple. Ces prédations capitalistes ne sont pas nouvelles ; Google avait réussi à torpiller XMPP il y a un moment, et impose ses règles concernant les courriers électroniques avec Gmail.

Et forcément, la pub, la pub, les pisteurs, la pub, la pub... qui explosent la taille des pages web et consomment davantage de bande passante.

Bref

Le web est devenu trop compliqué. Nous avons oublié comme faire simple. On créé tous les jours du code legacy. On est devenu dépendant d'un navigateur. On est face aux géants du numérique qui cloisonnent tout. Le développement web est un développement au rabais. Le web 2.0 a créé des dindons arrogants entretenant la fabrique du mensonge et la superficialité. Le web est trop ravagé par les capitalismes de la donnée, de l'attention et de la surveillance. On a oublié toutes les valeurs initiales du web, et la merdification continue.

J'espère qu'on aura de belles histoires avec Gemini par exemple. Ou Kittens et le small web, ou le slow web.

Le web pue la merde, je ne l'ai jamais autant détesté qu'aujourd'hui. Il était émancipateur. Il est devenu privateur.

Quelques ressources en vrac pour aller plus loin et réfléchir un peu

1 – Sur le web environment integrity 2 – Firefox meurt 3 – À propos du small web 4 – Meta et le fediverse 5 – On peut avoir un autre web 6 – A brief history of web development. And why your framework doesn't matter. 7 – L’apocalypse Google avec le web synthétique 8 – Tracking Protection in Firefox For Privacy and Performance 9 – Et si on faisait du web comme en 1999, ou presque ? 10 – Spritely and Veilid: Exciting Projects Building the Peer-to-Peer Web 11 – Tariq Krim : le slow Web à la française 12 – The SOLID project 13 – Retour d'expérience concernant le navigateur web Brave 14 – Privacy or sensitive data… a list of tools to protect your дѕѕ 15 – Le jour où le Web s’enfonça un peu plus dans la tombe

Wall of shame

— Dernière mise à jour : lundi 23 décembre 2024 🎃 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇺🇸 – Last update: Monday, January 12th 2026

Keywords: #Git, #commits, #GitHub, #GPG, #CLI

A bit of context

Sometimes I need to get back some commands I used in my terminal so as to work on my Git repositories of GitHub / GitLab projects. But I can have often some doubts about them, so I decided to list here some useful commands as a cheatsheet or a simple reminder to keep and share. I will try to keep it updated. There are nice resources in the bottom of this document!

Applying some common Git configurations

Use also the —global option if you want to apply this configuration everwyhere.

Showing GPG keys to get ID to use for commits

Useful to remember the ID of the GPG key to use to sign commits. More details in this other publication (in french).

Verify GPG signature of commits

Keep in mind the software forges like GitHub and GitLab provide also some verification process for commits.

Verify GPG signature of artifacts

Verify assets or release integrity (GH)

Display contributors of a commit

You can also filter to get other metadata in commits, find here for example some ideas.

Create branch from another and switch

That's not the only command of course, but I like this one.

Get rid of the last N commits

You can use of course other things instead of HEAD~N.

Reword, reorder or squash last N commits with interactive rebease

You can use of course other things instead of HEAD~N. Beware of fixup and squash, not the same uses with the commit messages.

Create a Git patch

Allows to generate a Git patch from a diff to apply or send it later.

Keeping somewhere changes temporary

Useful for drafts or temporary changes you don't want to version.

Find someone to blame (maybe you!)

The aim is to display who modified lines of files.

Clean the repository

Clean the project, get rid of files, but beware, you may loose things!

Work on a fork and submit

The workflow is simple: fork, create local develop branch with your dev stuff, make meaningful commits, then cherry-picks from this branch to a virgin one so as to submit a nice and simple pull request.

Resources

You have also some online resources like git-cheat-sheet.readthedocs.io.

But, maybe most important, you can refer also to this amazing comic of Julia Evans, available online and also buy her book. Her comic bellow is licensed under CC-BY-NC-SA 4.0.

[Code samples rendered with carbon.now.sh]

— Posted on Friday, September 27th 2024 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇫🇷 – vendredi 19 avril 2024

Mots clés : #AAEE, #ENSSAT, #associatif, #social, #fatigue

Depuis le temps, il faudrait peut être exorciser le truc pour passer à autre chose. Avec le temps, je me rends compte que la ressource la plus précieuse que l'on ait est le temps justement. Temps qui, comme la fatigue, peut être notre ennemi. Et quand on fait de l'associatif, qui est vraiment important en soit si on s'y retrouve et que l'on a l'impression d'être utile, le temps et la fatigue peuvent jouer énormément.

J'ai obtenu mon diplôme d'ingénieur “informatique, multimédia et réseaux” à l'ENSSAT, sur Lannion, école d'ailleurs que je recommande tant pour son équipe éducative, les enseignements, les intervenants extérieurs, le programme et aussi la volonté de toujours faire mieux. C'était en 2015, et j'ai rejoint son association d'anciens élèves en 2016. Si c'était à refaire, je le referais sans hésiter.

L'ENSSAT est une “petite” école d'ingénieur, mais qui bouge et qui grossit. Son association d'anciens élèves, l'AAEE, est aussi de taille modeste. En effet, on est loin de ces très grandes écoles corporatistes, usines à ingénieurs de salon généralistes, avec des réseaux d'anciens énormes, qui parfois ont pour travers de maintenir le réseautage et l'entre-soit. En rejoignant l'association, j'avais envie de m'y investir, de faire des choses pour elle et pour l'école, et aussi de travailler sur ça avec d'anciens élèves, d'anciens camarades, et si ce n'était pas encore le cas, de bons potes. Mais 6 ans après, il était temps d'arrêter, de suivre de loin et de soutenir comme je pouvais, car le temps disponible se faisait rare et l'énergie n'était plus là, alors autant ne pas s'acharner si on a fait sa part. Je n'aime pas l'idée de faire du job protection et de garder sa place au chaud ; si je ne sers à rien, je sors.

En soit, le bilan n'était pas si mal. On a organisé des évènements comme des afterworks dans différentes villes, la traditionnelle rencontre annuelle entre étudiants et anciens, et aussi des brunchs. En plus de ça, du relai d'information aux diplômés, des discussions avec IESF, de la communication sur les réseaux sociaux et d'autres chantiers plus ou moins inachevés. Un autre projet important concernait la caisse de secours que l'on maintenait pour les étudiants en galère, que ce soit pour avancer des frais ou parce que les fins de mois étaient trop difficiles. Ça fait se nouer le ventre, mais ça permet de garder les pieds sur terre. Au moins on en aura aidé et sorti de la galère.

Le sujet de cette caisse de secours était épineux. D'une part des étudiants, une fois diplômés, et avec des situations correctes, malgré les relances, refusaient de rembourser les prêts d'honneur qu'on leur avait octroyés pour les sortir de la merde. On s'est posé la question de passer par un huissier ou une entreprise spécialisée, mais ça nous aurait coûté encore plus d'argent sur un budget serré. Et d'autre part, des diplômés se permettaient de critiquer nos actions ; on se faisait reprocher d'aider des étudiants en galère alors qu'on ne leur payait pas les premiers verres en afterworks, à eux (qui avaient une activité salariée). Peu importe l'école, il y aura toujours de beaux connards.

Un autre sujet pénible était le peu de retours sur nos afterworks. La chose est d'une simplicité dingue pourtant : chercher un bar, convenir d'une date, et venir. Pour ces évènements, on a eu peu de monde par moment, et pour ceux qui ont bien marché il a fallu vraiment insister pour faire venir du monde. Pire encore, des lieux avaient été réservés pour un nombre de personnes ayant accepté de venir, et les entrées étaient bien en dessous des chiffres prévus. Manque de respect et fatigue de voir que des adultes ne sont même pas capables de tenir un engagement ou de prévenir.

On nous a reproché de ne pas être visible sur les réseaux sociaux. Toujours preneurs de remarques et suggestions, on a amélioré la chose : Twitter (pas encore X à l'époque), Instagram, Mastodon, une page publique LinkedIn et une refonte du groupe privé. Même avec ces efforts, pas de retours, pas d'avis, pas d'abonnés. On avait même mis en place un serveur Discord pour favoriser les échanges et le partage d'information, et ça ne décolle toujours pas. Le bilan était décevant, et on ne comprend pas pourquoi ça n'a pas décollé.

On avait aussi pas mal travaillé sur le partage des cours aux anciens diplômés afin de favoriser la diffusion des connaissances. Ce fut une belle galère ; entre les problématiques techniques de la plateforme à choisir et les réticences de certains enseignants, on n'avait finalement pas pu aller bien loin.

L'autre sujet le plus chaud concernait IESF. J'ai une particulière aversion pour les corporatismes de tous bords et de tous poils, qui se contentent d'exister et se tapent sur le ventre à la moindre occasion de rappeler qu'ils sont là. Cette association était pénible et le dialogue était plus que compliqué avec. En même temps, les conseils d'administration de ventres bedonnants et de cheveux blancs semblent bien, bien loin de la réalité du terrain et du métier d'ingénieur ainsi que des associations d'alumni qui ne sont pas assez grosses et prestigieuses pour eux. Déjà, la cotisation à payer tous les ans était exorbitante et représentait une partie énorme de notre budget. Pourtant, les services disponibles en contre-parties ne nous étaient d'aucune utilité. Peut-être que pour de grosses et vieilles associations parisiennes ils l'étaient, mais pour le reste du pays non. Malgré des tractations pénibles ayant réussi à leur arracher une réduction dérisoire de 50 €, l'adhésion était à 500 € par an. Près de la moitié de notre budget pour louer des salles sur Paris à prix réduits, bénéficier du service Labellis pour certifier via blockchains les diplômes, et inscrire les étudiants au Registre National des Ingénieurs (RNI), chasse gardée d'IESF, c'est non. Car oui, même si on a un diplôme d'ingénieur, validé par la CTI, on peut ne pas être dans ce RNI car une association poussiéreuse fait du gate keeping. On a pourtant demandé des métriques sur ces services : qui les utilisent, combien de requêtes sont faîtes, quels types de résultats, bref on voulait savoir dans quoi notre argent allait servir. On n'a jamais eu les chiffres demandés à part des approximations grossières au pifomètre. On nous affirmait que des milliers de requêtes étaient faîtes par mois sur le RNI ; un débugueur de navigateur web nous montrait que la saisie de chaque caractère dans le formulaire de recherche envoyait une requête. Autrement dit, si je saisis mon nom, j'envoie 10 requêtes, de quoi donner des chiffres incroyables ! Outre le fait que l'autocomplétion n'est pas compatible avec l'ecoconception et n'est pas vraiment recommandée dans le RGESN, ce calcul grossier de métriques est ridicule. “Ingénieurs et scientifiques” donc. Les prises de contact en direct n'aboutissaient pas, il fallait les chatouiller sur les réseaux sociaux pour susciter des réactions agacées, mais amenant quand même la possibilité de discuter un peu. Ce ne fut pas utile in fine, mais bon, au moins leur responsable communication s'est donné la peine d'échanger, merci à lui. On avait réussi à remonter le fait qu'IESF était trop franco-parisienne et exclusive, ce qui a mené à une création maladroite d'entités régionales IESF, plus ou moins inféodées à la structure principale, mais pas trop. Dit autrement, pour profiter de IESF Bretagne, il fallait adhérer à IESF Bretagne. Pour profiter d'IESF France, il fallait y adhérer aussi, donc double peine, double adhésion, encore plus de dépenses. Et l'entité nationale ne soutenait pas d'une quelconque manière l'entité régionale, pas la bretonne en tout cas. Bref, quand le budget d'une association est constitué des dons et adhésions de ses membres, c'était dur de justifier ce gaspillage de moyens pour des services rendus inutiles ou dont l’utilité n'était pas démontrée. À la fin, on a finit par se faire exclure, n'ayant pas payé notre dernière cotisation. On nous avait même dit que les temps étaient durs pour eux aussi ; en même temps quand on voyait les bilans en assemblées générales, il aurait été facile d'économiser sur certaines rémunérations, les cocktails et des services payés bien trop chers. Ils nous demandaient même de payer pour avoir le résultat des enquêtes d'insertions des ingénieurs que nous avions nous-mêmes relayés auprès de nos diplômés ! À force de les secouer, nous avions enfin pu avoir un échange entre le président de IESF et la présidente de l'association de l'époque. Mais bon, ils nous auront vite oubliés je pense, à défaut d'avoir vraiment pensé aux petites structures. C'est pas faute d'avoir tenté de rejoindre le poste d'administrateur IESF sans succès.

En plus de ça, les critiques des uns et des autres finissaient par être pénibles à encaisser. Entre les anciens qui critiquent sans s'investir ou comprendre, et les étudiants qui font de même, dur de consolider la diaspora enssatienne et d'en faire quelque chose de chouette. Heureusement que l'on avait quand même des anciens qui étaient là et savaient soutenir au besoin. On sait sur qui on peut compter.

On a eu aussi pour projet de valoriser certains profils de femmes ingénieures, ou encore de faire des témoignages de personnes étant dans de grands groupes, peut-être qu'en flattant les égos ça aurait marché : Saint Gobain, Ubisoft, Arkéa, Cisco et SFR, Airbus Helicopters, Philips, ING, Sagem, VMWare, Decathlon, Google, STMicroelectronics et NXP, Enedis, Betclic, Huawei, Amadeus, Nokia, Microsoft, le CEA, NVIDIA, Oracle, mais aussi à l'époque Intel, Facebook, l'Armée de l'Air et de l'Espace..... Bref il y avait moyen de faire quelque chose. Certains n'ont jamais répondu ou voulu répondre, et quand aux données récoltées et analysées, peu de personnes dans l'association ne voulaient les exploiter et contacter les anciens ayant répondu.

Autre point de crispation, des divergences de point de vue avec certaines instances de l'école. Jusque là, on s'occupait de grossir l'association et de s'affairer à construire la diaspora enssatienne, en reprenant contact avec tout le monde. Mais avec le nouveau conseil de l’époque, il y avait trop de divergence. Les cheveux blancs du monde d'avant préféraient que ce soit l'association qui verse une cotisation à l'école, sans forcément réfléchir aux conséquences que ça avait, et la direction de l'école préférait s'aligner sur les autres établissements en ne soutenant pas la cotisation à IESF.

Concernant les finances, on avait ponctuellement et marginalement du sponsoring d'entreprises locales notamment pour éditer nos annuaires papiers. On a pu creuser le sujet aussi d'être reconnu d'intérêt général ou d'utilité publique, mais les associations d'anciens élèves ne sont pas compatibles avec ces critères. Ainsi, pas de dons défiscalisés possibles, donc peu d'entrées d'argent.

Et à ça s'ajoutent les autres crispations : peu de réponses des diplômés, peu d'investissement d'une partie du conseil d'administration, concours de yakafokonsufide, des critiques de toutes parts... bref il fallait s'arrêter.

Y'avait encore pas mal de choses à faire : faire des interviews des diplômés, chercher des faits marquants des anciens, se rapprocher d'entreprises pour leur parler de la taxe d'apprentissage, mettre à jour le site web, gérer le recouvrement de la caisse de secours, dynamiser l'année avec des évènements dans plusieurs villes... mais trop peu de moyens humains n'étaient mis, même pas un tiers du conseil d'administration à faire tourner la boutique, et faisant partie du reste des personnes actives, ça m'a usé d'en faire autant avec si peu de copains.

C'est con, mais ça fait du bien de se vider la tête une dernière fois pour ne plus y penser. Au moins j'ai gardé de bons potes qui se reconnaitront, le noyau dur du conseil d'administration, les vieux schnocks. J'ai constaté qu'avec d'autres membres du bureau il y avait trop de divergences de points de vue sur la façon de faire, autant partir plutôt que de laisser les relations se dégrader et finir fâchés.

On aurait pu faire tellement plus et bien mieux, mais bon, c'était chouette quand même. Bon courage à celles et ceux qui prendront la suite.

— Dernière mise à jour : mardi 23 avril 2024 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇫🇷 – dimanche 9 janvier 2022

Mots clés : #opensource, #FLOSS, #GitHub, #licences, #social

D'ordinaire nous aimons utiliser des bibliothèques tierces dans nos projets, ces “librairies” que l'on retrouve par exemple sur des forges logicielles publiques comme GitHub et GitLab. Rares sont les logiciels qui ne possèdent pas une once de FLOSS (Free Libre and Open Source Software) à l'intérieur. Le plus souvent, on retrouve dans chaque projet des composants FLOSS, que ce soit pour se faciliter la vie, écrire des tests unitaires ou gérer une base de données par exemple. On a vite tendance à prendre l'outil le plus connu, le plus répandu, ou à faire des réflexions trop rapides pour choisir ce dont on a besoin, et pourtant il y a des pièges à éviter.

Tout le monde est juriste, évidement !

Beaucoup (trop) d'entre nous ne considèrent pas suffisamment la licence qui est appliquée à la libraire choisie ; par paresse intellectuelle, par pure fainéantise, par certitude de bien comprendre les licences, par oubli, ou par excès de confiance. On fait tous la boulette, et on en tire des leçons ensuite, ce n'est pas si anormal quand encore aujourd'hui dans les établissements de formation à l'ingénierie logicielle ou “les écoles de codage” on en parle assez peu, ou pas assez, voire pas du tout. Merci les formations au rabais vendeuses de rêves laissant leurs apprenants se fracasser sur le mur de la réalité.

Toutefois, parmi les pièges dans lesquels chacun et chacune peuvent plonger, il y en a particulièrement qui sont beaux. Et grossiers. Et pourtant, beaucoup de personnes se font avoir, et ne finissent par réagir que lorsque le sujet est médiatisé. Avant de se jeter sur le dernier composant à la mode, regardons en détails les pièges, en commençant par les licences évidemment.

Des clauses déloyales dans les licences

Par exemple, il y a quelques années, on pouvait trouver les frameworks React de Facebook / Meta sous une curieuse licence “BSD + Patents”. Le truc, c'est que cette licence possède des clauses relatives aux brevets (une vague idée ici). Si j'exagère et grossis les choses, le fait de chercher des noises en justice à Facebook à l'époque pouvait faire tomber le droit que vous aviez d'utiliser ses cadriciels (j'adore ce mot). Pot de terre contre pot de fer dans du béton armé, embêter Big F peut revenir à vous interdire d'utiliser ses technos, donc à retirer beaucoup de produits. Une fois la chose médiatisée, finalement Facebook changea son fusil d'épaule et utilisa la licence MIT.

Bref, attention aux clauses déloyales des licences !

Des changements radicaux de licences

Récemment encore, c'est HashiCorp qui changea brutalement la licence de son produit phare nommé Terraform, et l'entreprise est dans son bon droit. Le passage de la licence MPL 2.0 à la Business Source License a été fait avec fracas, justifié maladroitement par l'entreprise et décrié par la communauté open source. MongoDB a eu droit aussi auparavant à son concert de casseroles avec le passage à la SSPL. Pour aller plus loin, MariaDB propose cette page de FAQ sur la BSL. Benoit Sibaud (un chouette collègue chez Orange !) a rédigé et diffusé un billet abordant les “virevoltantes valses de licences libres et non libres dans les bases de données”, très instructif ! En d'autres termes, attendez-vous à peut-être voir des revirement de situations dingues sur les licences appliquées !

Le truc, c'est que quand bien même une entreprise décide d'agir ainsi, elle reste tout de même légalement dans l'obligation de satisfaire les demandes qui concernent les licences anciennement appliquées. Autrement dit, si à un instant T un composant C était sous une licence libre L (admettons GPL 3.0), mais que plus tard cette licence passe à une bullshit licence BL, si vous avez eu le composant sous licence L vous êtes en droit de demander les sources (si L l'autorise évidement), même si elles ne sont pas accessibles publiquement. Bon courage donc.

On peut ainsi imaginer jouer la prudence, et se dire que si on utilise des composants FLOSS, dans le doute, au cas où, on pourrait garder une copie du code source. J'apprécie beaucoup cet article de Geoffrey Dorme qui vous donnera davantage de motivations à le faire. En plus cloner les dépôts Git d'une organisation GitHub c'est facile pour l'instant.

Imaginez maintenant, malgré les trahisons précédentes, que certaines technos soient si répandues qu'elles en deviennent presque indispensables pour des entreprises, au hasard les frameworks comme React. Rien n'empêche Facebook / Meta du jour au lendemain de changer la licence, de rendre l'exploitation de l'outil payante, et de monter un vrai business model dessus. Un magnifique coup à jouer maintenant que le place est faite dans l'écosystème logiciel. Impossible ? C'est vite oublier le ramdam lorsque Oracle avait mis en place son JDK payant.

Mais il y a d'autres pièges plus gros encore...

L'ajout de clauses additionnelles

Prenons par exemple une librairie Java bien connue, qui est utilisée en production : Realm Java (la situation a été corrigée depuis, mais a trainé un bon moment tout de même pour que ce soit notable).

À première vue, si on regarde le README vaguement, on voit ceci :

On peut alors en déduire que le composant est sous licence open source Apache 2.0. Sauf que trop de gens s'arrêtent là. Car que si on jette un œil au fichier de licence, on trouve certes des références à la licence Apache 2.0, mais aussi un autre élément d'enfoiré : l'export compliance.

Vous pouvez retrouver le diff du commit sur GitHub, je vous met ci-dessous le contenu scélérat de cette clause, qui rend la licence non conforme à la définition donnée par l'OSI, donc plus open source du tout.

Pour celles et ceux qui n'ont plus assez de caféine dans le sang pour comprendre, voici un résumé : si on se retrouve sur une liste noire du gouvernement américain, que ce soit dans un pays, ou individuellement, ou dans une entreprise détenue par une personne dans cette liste noire, on ne peut pas utiliser ce produit.

En soit, quel est le soucis ?

Et bien le soucis est que l'on peut avoir des applications critiques ou indispensables, ou son produit tout bêtement qui, si un jour le client, l'éditeur, le pays, les actionnaires etc. sont dans le collimateur des États Unis d'Amérique, peuvent être dégagées des boutiques d'applications, avec toutes les conséquences que ça implique.

On peut espérer que ça n'arrivera jamais, ceci dit l'ère Trump a montré qu'il ne fallait pas grands choses pour que des fous furieux mettent la pagaille à l'échelle mondiale en interdisant l'usage de produits. Et le contexte international actuel ne rassure pas non plus vis à vis de la Russie. Demandez leur avis aux iraniens, cubains, ukrainiens ou chinois.

Bref, dit autrement, quand vous utilisez une librairie FLOSS, regardez sur GitHub la section dédiée à la licence. Si le texte “View licence” apparaît au lieu du nom de la licence, il y a deux cas de figure :

• le texte a été modifié (souvent les copyrights) ou décoré faisant que GitHub s'y perd ;
• il y a du texte en plus dans le fichier. Ceci pouvant être des détails sur d'autres licences appliquées ou d'anciens contributeurs, ou des clauses additionnelles.

Et oui, tout ça en droit français est valable.

Mais où ailleurs peut-on se faire avoir ?

La plaie de l'excès de social dans les forges logicielles

Et si on regardait le nombre de commits ?

Déjà, pour “évaluer” un composant FLOSS, on peut regarder par exemple la vie de son code source. Ainsi, si un projet a des commits faits régulièrement, on serait en droit de se dire qu'il est toujours vivant. Toutefois la contraposée est fausse car on peut très bien avoir des projets FLOSS qui semblent “vivoter”, avec peu de commits réguliers mais qui fonctionnent très bien, tout simplement car le projet en lui-même peut être maintenu ponctuellement, discrètement, mais efficacement.

D'ailleurs regarder la date et le nombre de commits est aussi une fausse bonne idée, car par exagération on pourrait croire qu'un projet qui a beaucoup de commits est un projet de qualité, et fiable, ce qui est absurde. Dans la mesure où des outils comme Git permettent le squashing, les merge commits et le rebasing, on remarque bien que se fier uniquement à un historique de commits n'est pas viable. De plus, doit-on vraiment prendre en compte les commits et pull requests ridicules qui arrivent lors du Hacktoberfest quand celles et ceux qui les proposent veulent juste profiter du moment pour avoir un joli badge sur le profil GitHub par pur opportunisme ?

Est-ce que pour l'exemple ci-dessous le projet est vivant ou mort ? On peut s'y fier ou pas ? Pour faire des confettis, c'est suffisant ?

Et Si On RegArDaIt LeS LiKes eT LeS FoLlOwErS ?

Les réseaux sociaux ont amené du pire dans GitHub avec les “likes” et les compteurs de “followers”.

Cet autre piège à éviter consiste à se contenter de regarder ces nombres de stars et de forks d'un projet sur la forge logicielle que l'on veut. Avec l'avènement des réseaux sociaux, on veut “liker”, “booster”, “up-voter” ou “starrer” des projets que l'on aime bien, ou que l'on pourrait aimer, ou pour faire plaisir au gars derrière qu'on connait. Mais en soit, ni le fonctionnel ni la qualité du projet ne sont par essence et par définition concernés. Il en est de même pour les forks ; il est courant de voir des utilisateurs en crééer juste... au cas où, pour grossir son profil GitHub, ou pour faire une pull request un jour ou pas. Surtout ou pas. Quand au nombre de “followers” du développeur principal, en quoi le fait qu'il en ait 2 300 au moins soit rassurant ? Le personnage peut être tout à fait exécrable, pénible voire même adepte de la pizza avec des patates dessus, pourquoi afficher cette fausse notoriété qui n'apporte rien ?

Est-ce que l'exemple ci-dessous est un gros projet ? Un truc balèze ? Non, c'est juste un programme affichant un train à vapeur si on se trompe de commande (moi j'adore).

Oh, et puis, bien évidemment, on peut acheter des “stars” sur GitHub à prix réduit ! La plaie du social jusqu'aux forges logicielles, et à portée de main. Cet article est très instructif sur le sujet.

Environnement et qualité, beau code ou infect projet

On regarde les issues et requests ?

Un autre élément à considérer avec prudence est le nombre de issues et de pull requests / merge requests. En effet, un projet qui en possède beaucoup peut être un projet très vivant, comme aussi un projet qui est très à l'abandon mais avec une base d'utilisateurs réclamant des choses ou voulant contribuer sans personne derrière pour valider. Ou alors peut être victime de trolls, comme ce fut le cas pour le dépôt contenant l'algorithme de recommandations de Twitter. Prudence donc si on ne regarde que ces éléments sans les contextualiser.

On regarde les contributeurs ?

Chose intéressante aussi à voir, les contributeurs, ces petites mains visibles fournissant un incroyable travail.

Si vous utilisez un composant FLOSS avec un faible nombre de contributeurs, il est possible que derrière ce projet il n'y ait presque personne en dehors de quelques passionnés dévoués (bénévolement le plus souvent) à leur projet (pour la gloire plus que pour l'argent). Il faut donc se demander si le fait que le projet repose sur un tout petit nombre de contributeurs est bloquant ou pas. Pour une librairie affichant de confettis c'est peut-être un élément peu pertinent. Mais pour votre couche de chiffrement, est-ce une bonne idée de compter sur un seul péquin derrière ?

D'ailleurs, question bête, est-ce que l'on suppose que la source de vérité est... fiable ? Car pour être affichés comme contributeurs sur un projet GitHub, il faut apparaître à certains endroits dans les commits. Quid des personnes voulant rester anonymes ? Des personnes en pair-programming ? Ou d'une organisation faisant que le mainteneur principal s'acharne maladroitement à garder un historique Git propre et donc fait du copier/coller des pull requests mais en gardant à jour le fichier AUTHORS par honnêteté intellectuelle ? Ou des robots qui exécutent des tâches automatisées sur le dépôt et qui figurent dans les contributeurs ?

Ci-dessous un exemple, avec le projet Amaroq. A-t-on vraiment 13 contributeurs ou 1 seul ? D'ailleurs peut-on vraiment se contenter de mesurer l'activité par le nombre de commits ? Non, évidemment.

En parlant de commits et des contributeurs, peut-on vraiment faire confiance aux contributions ? Il y a des projets FLOSS qui exigent des signatures cryptographiques des commits d'une part, et que le Developer Certificate of Origin soit appliqué d'autre part. Engager les responsabilités de chacun et s'assurer que les commits soient intègres ne semble pas une mauvaise idée, mais a-t-on toutes et tous l'habitude de le faire ? Non. Méconnaissance ou fainéantise ?

La doc ?

D'ailleurs, on peut aussi regarder les échanges qui ont lieu dans les issues, les Slack ou Mattermost. Pour ce composant FLOSS qui vous intéresse, peut-être ne seriez-vous jamais amenés à échanger avec les mainteneurs derrière. Mais si vous voulez contribuer, êtes-vous prêts à dialoguer avec une équipe ayant une organisation pyramidale ? Ou concentrée sur un développeur quasi-messianique à qui tout le monde demande son avis et attend son accord ? Est-ce que l'ambiance est délétère dans le projet ?

On regarde le code source alors ?

Par ailleurs, jetez un œil aussi au code source en lui-même.

Si vous avez un projet iOS écrit en Swift, avec uniquement des compétences en Swift dans votre équipe, seriez-vous prêt à soumettre des pull requests sur un composant écrit en bon vieux Objective-C à la papy ? Si une librairie JavaScript vous plait pour faire des jolies animations, ça vous tente vraiment de l'utiliser sachant qu'elle va tirer jQuery et que vous êtes fiers de vous en être débarrassés y'a 2 ans ? Si le CERT signale de vulnérabilités critiques, et que le composant que vous voulez est concerné, comment et à quelle vitesse sont corrigées ces failles ? Il y en a certaines qui ne le sont toujours pas ? Et ils feront comment si le Cyber Resilience Act passe ? Si on voit plusieurs issues sur des vulnérabilités non corrigées, remontées par Dependabot ou Snyk peut-on nécessairement en conclure que ce composant est dangereux alors qu'un autre sans de telles choses le serait moins même si finalement il pourrait n'avoir en place aucun outil de détection ?

Les gens c'est bien aussi non ?

Truc rigolo, vous connaissez le développeur / grand chef derrière le composant que vous voulez ? Car peut-être politiquement engagé ou susceptible, ou impulsif, ou infect, et qu'il va saboter son projet ou pas, quitte à se faire virer de GitHub. Impossible ? Voyez plutôt.

D'ailleurs, pourquoi c'est là ?

Ce n'est pas parce que le code est sur GitHub, avec une licence libre ou open source que forcément cela a été fait avec une volonté de respecter la philosophie de l'un ou la méthodologie de développement de l'autre.

Par exemple le code a très bien pu être publié juste pour des raisons de transparence totalement opportuniste comme l'algorithme de recommandation de Twitter, maintenant X. Ou alors le code est publié car il embarque un composant sous licence à copyleft fort qui implique une mise à disposition du code source. D'autres projets peuvent être open source pour attirer des contributeurs très rapidement et aussi éviter toute polémique en pleine période de crise, tant sur le manque de fonctionnalités que sur le fonctionnement, sans pour autant avoir des perspectives sur le long terme. Ou alors certains projets décident de se mettre en open source pour faire comme les concurrents et tout avoir public et sans vraiment de contributions venant de l'extérieur, pour le moment, ce qui est dommage car la qualité du produit est là. Ou juste pour montrer ce qu'ils savent faire mais avec des licences ni libre ni open source, pour avoir quelques contributions mais juste avec le code source public. C'est trompeur, mais correct. Mais on a aussi des dépôts open source car une communauté s'est formée autours de l'outil, et là c'est chouette. Plus chouette qu'exposer des projets comme des design system alors que les seuls utilisateurs pourraient être des filiales ou partenaires, qui se serviront gratuitement, plutôt que d'être facturés.

Bref... ce n'est pas parce que le produit est joli sur la vitrine, bien placé en tête de gondole avec un emballage coloré qu'il faut forcément sauter dessus. C'est bien de regarder la date limite de consommation, les ingrédients, les excipients et les origines.

Du coup...

Du coup, il n'y a pas de bons ou de mauvais composants FLOSS. Et non, cette réflexion n'est pas de la “branlette intellectuelle”, bien au contraire. Certains composants sont d'apparence plus fiables que d'autres, il faut les juger par leur efficacité mais pas uniquement ceci dit. Il faut rester prudent sur les licences altérées, bâtardes ou simplement sur leur nature intrinsèque. S'intéresser à l’environnement, à l'ambiance, aux commits et au code source est une bonne chose également.

Il faut aussi envisager le fait qu'un projet finisse par mourir, que sa core team abandonne, que le moteur s'épuise. N'attendez pas pour les soutenir. N'attendez pas pour contribuer. N'hésitez pas les soutenir s'ils défendent des causes justes. L'open source c'est comme une kombucha : c'est super de récupérer une souche mère pour faire vos boissons, mais c'est mieux de partager vos souches filles à d'autres personnes pour qu'elles fassent pareil. À rester dans votre coin tout finira par pourrir et vous n'en tirerez plus grands choses. Prenez, améliorez, partagez et profitez.

Si vous voulez quelques pistes pour aborder les projets FLOSS, je vous partage ce support documenté, factuel et juste.

— Dernière mise à jour : mercredi 17 octobre 2023 Précédemment sur paper.wf —