Organisatrice : Nous allons d’abord t’écouter pendant 40 minutes et ensuite tu répondras aux questions des différents membres du jury. On commencera par les rapporteurs puis les examinateurs. C’est parti pour 40 minutes.

Edlira Nano : Bienvenue.
Ma thèse s’intitule « Obsolescence logicielle : analyse et stratégies de remédiation ». Elle a eu lieu ici, à Lyon 1, sous la direction d’Aurélien Tabard.
Merci au jury d’être en ligne et ici présent. Nous avons un live PeerTube et si, à un moment, il dysfonctionne, on ne va pas forcément pouvoir s’en occuper, donc désolée, on va mettre la priorité sur la vision et la soutenance.

Objectif

Ma thèse porte sur l’obsolescence logicielle, mais l’idée c’était d’analyser l’obsolescence numérique en général, avec un focus particulier sur le logiciel, les stratégies de remédiation en se plaçant dans un contexte d’impact environnemental grandissant des technologies numériques et aussi de rallongement de la durée de vie des terminaux.
Pour ce faire, j’ai choisi d’étudier deux écosystèmes logiciels :

• d’abord Android parce qu’on y voit un taux de renouvellement fort des terminaux
• et ensuite Debian, parce qu’on a une culture forte de maintenance logicielle dans cet OS [Operating System], système d’exploitation en français.

Cadre de thèse

Ça a eu lieu dans l’équipe SICAL [Situated Interaction, Collaboration, Adaptation and Learning] au laboratoire LIRIS [Laboratoire d’InfoRmatique en Image et Systèmes d’information], ici à Lyon, et aussi dans le Collectif de recherche Limites Numériques, un collectif interdisciplinaire entre design, informatique et études des sciences et techniques.

Positionnement personnel

Dans mon positionnement personnel, j’ai aussi un engagement associatif auprès de deux associations : l’April, qui est l’association de défense et de promotion des logiciels libre, et La Quadrature du Net [1], qui est une association de défense des libertés fondamentales en contexte numérique. Je le dis parce que cela m’a aidée dans ma recherche, ça m’a permis d’avoir une proximité avec les terrains que j’ai étudiés, je fais partie, en quelque sorte, de ces communautés que j’ai étudiées. Il y a eu un enrichissement mutuel des activités de recherche et associatives, mais ça a demandé aussi peut-être un point de vue un peu plus réflexif, parfois quand on est trop dedans, trop impliqués dans une communauté, on peut rater des choses ou ne pas les voir tout à fait de la même façon que si on était un peu plus externe.

Table des matières

Je vais commencer par présenter un état de l’art des définitions de l’obsolescence et des discours sous-jacents,
ensuite, on va plonger dans l’étude du cas Android dans de la production de l’obsolescence logicielle,
puis dans les stratégies de maintenance dans Debian dans un troisième temps.
Je vais aussi vous parler brièvement d’un travail coécrit avec Jeanne Guien qui se nomme « L’obsolescence : modèle économique du capitalisme numérique », qui est le dernier chapitre de cette thèse,
et ensuite on va conclure.

Partie 1 – L’obsolescence : état de l’art des définitions et discours

Le renouvellement des terminaux

Pourquoi s’intéresse-t-on à l’obsolescence ? Parce que le renouvellement des terminaux représente une part importante de l’empreinte carbone du numérique au niveau mondial mais aussi en France.
Ce sont surtout les phases d’extraction des matières premières de fabrication et de fin de vie des terminaux qui en représentent la majeure partie.
Au-delà des émissions carbone, on a des effets sociaux, environnementaux, sur la vie et la situation politique et sociale dans les territoires concernés, il n’y a pas que les émissions carbone qui entrent en jeu.

Fin de vie et déchets électroniques

Donc, d’une part, on a la fabrication des terminaux et, d’autre part, on a la fin de vie avec le problème des déchets électroniques qui sont aussi en augmentation constante. Des recherches montrent que le problème des déchets reste largement sans solution et insuffisamment évalué.
Du coup, dans ce contexte, faire durer les terminaux numériques n’est certes pas suffisant mais semble nécessaire, c’est une des raisons pour lesquelles on s’intéresse à l’obsolescence.

Obsolescence : quelques définitions et approches

Quand j’ai commencé cette thèse, je me suis dit que j’allais commencer par revoir un peu la définition ou les définitions de l’obsolescence une bonne fois pour toutes, dès le début, et, en fait, je n’arrête pas de trouver encore des définitions de l’obsolescence, je me suis rendu compte que ça dépend vraiment du contexte. Pour reprendre les mots de Proske and Jaeger-Erben : « L’obsolescence n’est pas une description neutre d’un état particulier d’un objet, elle prend des formes différentes selon le contexte, selon qu’on la gère, qu’on la planifie, qu’on l’utilise, qu’on la souhaite, qu’on la critique, etc. »
Je vais vous présenter quelques-uns de ces contextes. Il y en a davantage dans le manuscrit.

La gestion de l’obsolescence pour les besoins de l’industrie

J’ai commencé par regarder la notion de l’obsolescence en informatique et en génie logiciel dans le milieu de la recherche.
On remarque qu’à partir des années 2000 on a une recherche florissante qui s’intéresse à la gestion de l’obsolescence pour les industries : comment est-elle gérée dans les industries qui achètent les logiciels commerciaux ? On commence par la définir, ensuite on la modélise, on la prédit afin de mieux la gérer, et on l’a beaucoup appliquée dans des industries critiques clés – militaire, sécuritaire, aviation, train.
La personne dont la définition de l’obsolescence logicielle revient le plus souvent c’est Peter Sandborn [2], j’ai mis sa définition ici dans son état original en anglais. En gros, il l’a défini sous trois formes :

• l’obsolescence fonctionnelle qui est le fait qu’un logiciel s’arrête de fonctionner pour d’autres raisons, des raisons hardware ou logiciel
• l’obsolescence technologique qui consiste à l’arrêt du support ou des ventes du logiciel
• l’obsolescence logistique qui concerne le fait que la logistique, derrière ce logiciel, ne marche pas. Par exemple, le média dans lequel le logiciel est donné ne fonctionne plus, le format n’est plus compatible, des choses comme cela. Aujourd’hui, ce serait plutôt le service dans un cloud qui arrêterait de fonctionner.

La gestion de l’obsolescence logicielle pour et par l’industrie

Ces recherches sont aussi appliquées dans l’industrie à travers des institutions, on a par exemple l’Institut international de gestion de l’obsolescence [3] qui a des chapitres dans plusieurs pays dont un en France [4]. J’ai un peu suivi, pendant un moment, les séminaires en ligne. C’est un consortium qui mélange chercheurs, personnes clés, industriels clés qui essayent de gérer l’obsolescence pour eux-mêmes, [pourleurs besoins internes, Note de l’intervenante].
On a une publication de livres blancs et de rapports.
On a l’Obso-Days, une conférence annuelle dans laquelle des experts de l’obsolescence se réunissent pour en discuter.
J’ai remarqué chez des experts, dans les moments où j’ai pu les suivre, qu’il y a une mise en avant d’un discours de pérennité, de soutenabilité logicielle et même, souvent, de l’écologie. Cela jure avec le discours qu’ils ont quand il s’agit de parler des produits que parfois ils vendent, pas toujours, les industries critiques ne vendent pas souvent des produits de grande consommation, mais, parfois il y avait des personne, des entreprises qui vendaient ces produits [avec un discours qui met en avant l’obsolescence comme une technique de vente louable et même désirable, Note de l’intervenante].

L’obsolescence logicielle : entre discours de peur et stratégie de vente

Ainsi, dans ses travaux, Peter Sandborn se plaît toujours à mettre, en introduction surtout, une citation de Bill Gates qui, visiblement, l’a marqué, qu’il met un peu comme pour faire peur et pour justifier la raison pour laquelle il veut gérer l’obsolescence [dans la suite de son article de recherche, Note de l’intervenante]. La citation qu’il reprend, je vais la dire en français : « Les seules grandes entreprises qui vont réussir sont celles qui rendent obsolètes leurs propres produits. » J’ai essayé de la retrouver, la sourcer, parce que je voulais un peu plus de contexte autour de cette définition, je ne l’ai pas trouvée, j’ai beaucoup cherché, et, finalement, j’en ai trouvé une assez similaire, je ne vous la lis pas parce qu’elle est vraiment très similaire, que Bil Gates a écrite dans un livre autobiographique. Par là, je veux dire que Peter Sandborn utilise l’obsolescence mise en avant par Bill Gates en tant que stratégie commerciale, comme justification pour faire peur, donc gérer l’obsolescence. En cherchant cette définition et d’où elle venait, je suis tombée sur tellement d’endroits où elle est utilisée que j’ai remarqué qu’il y avait une réelle fascination, en fait, pour cette stratégie de vente que Bill Gates met en place.

L’obsolescence en tant que stratégie de vente : la fascination

Là c’est l’exemple que prend Peter Sandborn pour référence dans ses papiers. En fait, c’est un site internet qui n’existe plus, de news sur des placements produits. Ils envoient une newsletter, de temps en temps, où il y a des choses comme la méthode Bill Gates, la méthode gagnante, etc. Là, en 8^e point de la méthode Bill Gates, on trouve cette citation sur l’obsolescence. Je vous donne l’exemple le plus drôle que j’ai trouvé, qui était un catalogue de vente d’arcs de chasse où on avait un nouvel arc de chasse innovant qui venait remplacer, évidemment joyeusement, les autres arcs de chasse et on avait, dans ce catalogue, cette citation qui n’est même pas attribuée à Bill Gates.

Obsolescence et consumérisme

Il y a donc une fascination pour les stratégies de vente basées sur l’obsolescence, et des chercheurs travaillent dessus. Ça a été, et c’est toujours le cas, de Jeanne Guien [5], une philosophe des sciences et techniques. Elle a fait sa thèse sur l’obsolescence et le consumérisme, le livre tiré de sa thèse se nomme Le consumérisme à travers ses objets. Jeanne Guien a été très importante dans mon travail, elle m’a beaucoup inspirée quand j’ai commencé cette recherche.
Jeanne Guien prend des objets de consommation courante et suit leur histoire depuis leur apparition, la façon dont ils sont devenus indispensables : mouchoirs jetables, gobelets jetables, dedans il y a aussi les vitrines, les déodorants et aussi les smartphones. Elle prend l’histoire de ces objets-là et elle montre comment l’obsolescence n’est pas inhérente à ces objets mais est un phénomène qu’on produit, qu’on gère, qu’on planifie au sein de sociétés structurées autour de la production constante et continue de produits jetables et de la promotion de nouveaux produits à consommer. Elle montre aussi, dans ses travaux, que l’obsolescence n’est pas cachée, elle est théorisée en économie, en management et marketing, dès les années 30, comme une stratégie de vente à part entière.

Obsolescence planifiée

On a aussi l’obsolescence planifiée. L’idée, derrière ce terme, c’est qu’il y a une suspicion envers les entreprises qui feraient exprès de raccourcir la durée de vie de leurs produits pour forcer rachat et remplacement.
En France, on va plutôt parler d’obsolescence programmée – qui est très probablement une mauvaise traduction de planned, mais c’est la même définition. La France est le premier pays à avoir légiféré dessus en 2015, la définition est à peu près la même.

Maintenance logicielle

En ce qui concerne la maintenance logicielle, on sait que dans le secteur logiciel la maintenance fait partie du travail, et des chercheurs ont montré que ces tâches de maintenance constituent la majeure partie du travail, 60 à 80 % du coût total des logiciels.
Les mises à jour et le support logiciel sont importants pour assurer une longue durée de vie, et l’arrêt du support est un motif de remplacement, ça apparaît aussi dans des travaux. Ce qui apparaît également c’est que, du point de vue de l’utilisateur, ces mises à jour ne sont pas assez bien préparées, l’utilisateur n’est pas assez bien informé, les interfaces ne l’aident pas suffisamment. Il y a donc un manque là-dessus.

Logiciels libres, communs numériques : maintenance et soutenabilité

En ce qui concerne les logiciels libres et les communs numériques, là encore la maintenance est très centrale. Le rôle de mainteneur semble très important dans ces communautés. Geiger, Howard et Irani montrent que ce n’est pas uniquement du travail de réparation, il y a aussi un travail de veille pour rester à jour et dans l’air du temps.
Il y a aussi un point de vue qui va plus vers l’environnement et les impacts environnementaux. Comme les alternatives libres sont des façons de partir des Big Tech, des chercheurs considèrent que ce sont aussi une façon de partir du capitalisme consumériste, d’avoir un point de vue plus social et plus environnemental.
Euler considère que les communs numériques sont des formes sociales qui s’éloignent du capitalisme en allant vers la décroissance et la soutenabilité.
Shulz et ses coauteurs se penchent en profondeur sur les difficultés dans le chemin de la soutenabilité environnementale des communs numériques pour y voir les problématiques rencontrées, des façons d’y remédier.

La production de l’obsolescence logicielle : le cas d’Android OS

Maintenant je vais vous présenter l’étude du cas d’Android OS où on va voir de l’obsolescence logicielle apparaître.

Motivation

La motivation ici c’est qu’on a une durée de vie des smartphones très faible, entre 18 mois et trois ans et demi [selon les études et les pays, en France ça a un peu augmenté, on serait à trois ans et demi, Note de l’intervenante].
Les facteurs logiciels semblent importants selon les travaux de Léa Mosesso et de notre équipe ici. On constate que les OS sont très peu mis à jour, il y a subitement et rapidement, après la mise sur le marché, des arrêts du support et ces arrêts sont très peu transparents, parfois totalement inaudibles et silencieux.

Questions de recherche

Les questions de recherche auxquelles on voulait répondre sont :

• Comment Android est-il structuré ? Quels sont les acteurs impliqués ? Comment contribuent-ils au développement d’Android ?
• Qu’est-ce qui freine les mises à jour dans Android ? Sous quelle forme l’obsolescence logicielle se manifeste-t-elle ?
• Quelles sont les stratégies probables mises en œuvre par les acteurs pour remédier à ces problèmes, pour allonger la durée de vie des smartphones ?

Méthodologie

C’est une recherche qualitative – ce sera une recherche qualitative aussi pour Debian – basée sur trois points principaux :

• des entretiens choisis avec des développeurs ou membres des communautés
• de l’ethnographie lors de conférences
• et de la recherche documentaire.

Je vais détailler un peu.

Entretiens

Pour Android, j’ai fait 12 entretiens en un an et demi, en présentiel ou en ligne, avec des développeurs qui font partie de l’écosystème Android.

Ethnographie

L’ethnographie, c’était lors de conférences en présentiel ou parfois en ligne : communautés de logiciels libres, que j’ai notées, j’en ai fait quelques-unes.

Recherche documentaire multidimensionnelle

La recherche documentaire est multidimensionnelle dans les deux cas :

• documentation technique, beaucoup, sur Android, son fonctionnement, le noyau Linux, on va en parler, les Systems on a chip [SoC], qui sont des matériaux importants dans les smartphones
• de la veille média
• et des forums et sites spécialisés ou parfois grand public.

Analyse

L’analyse a consisté en plusieurs étapes de cartographie :

• cartographie des acteurs d’Android parce qu’il y en a plusieurs, c’est un écosystème très riche, de leur rôle et des relations entre eux
• cartographie des couches logicielles, leurs fonctions, les relations entre les couches et les relations couches-acteurs
• cartographie des débats et des controverses entre les acteurs ou relatives aux couches logicielles cartographiées
• analyse des fonctionnements techniques dans Android que ce soit matériels ou logiciels
• transcription automatique des entretiens puis manuellement. Je choisissais des citations qui me paraissaient importantes. En général, ces citations-là me servaient de point d’ancrage soit pour lancer un entretien quand j’avais besoin d’approfondir soit je voyais là quelque chose d’important à creuser par moi-même. Je sautais, comme cela, d’une citation choisie à une autre pour voir ce qui pouvait être pertinent à creuser et à transmettre. Ensuite, je remettais en contexte la citation et, une fois que j’avais plusieurs entretiens, je revenais dans le fichier des citations choisies parce que je trouvais que ça m’enrichissait à nouveau [une fois les points flous éclaircis et l’ensemble des entretiens et documents analysés, Note de l’intervenante].

Résultats

Je passe aux résultats.

Cartographie des couches logicielles des smartphones Android

La première chose qu’on a faite a été d’avoir une cartographie des couches logicielles très haut niveau des smartphones [diapositive 30].
On a le matériel, tout en bas. Dans le matériel, on a une petite couche logicielle qui sont les firmwares, du logiciel qui est intégré dans le matériel. Dans les smartphones on a des Systems on a Chip, une sorte de carte mère des smartphones où sont souvent soudées, l’une à côté de l’autre, la carte mère, le processeur, la puce graphique, etc. C’est un composant très important et, là-dedans, on a un firmware très important parce que c’est lui qui va communiquer avec le reste du matériel.
Au-dessus de ça on a le système d’exploitation qui va faire l’intermédiaire entre l’utilisateur et la machine puis les applications qui vont servir, justement, pour utiliser le matériel.

On a ensuite deux couches intermédiaires, je ne vais pas en parler tout de suite, une qui est celle des services background, sous-jacents, qui part du matériel jusqu’aux applications et ça va revenir parce que Google va beaucoup influencer cette couche-là.

Cartographie des couches logicielles et acteurs Android OS

Maintenant, pour Android, on va faire un zoom dans la couche du milieu, la couche OS [diapositive 31]. Là c’est un résultat, c’est le résultat de la cartographie de cette couche, de l’OS Android. En fait, on a une imbrication de plusieurs logiciels, de plusieurs couches logicielles, avec, à chaque fois, des acteurs différents qui sont aux manettes de ces couches.
Android est basé sur un noyau Linux, qui est un logiciel libre développé par une communauté de développeurs, la communauté Linux.
Au-dessus de ça Google va construire le noyau Android, Android common kernel.
Ensuite les vendeurs de SoC, mais aussi les vendeurs de téléphones – parfois les vendeurs de téléphones vont aussi être vendeurs de SoC, pas toujours mais parfois, par exemple Samsung – vont venir prendre cet ACK-là [Android Common Kernel] et vont ajouter du code propre à leur propre SoC ou à leur propre matériel – leur écran, leur batterie, etc. Cela va donner ce que, dans la communauté, on appelle un frankenkernel. J’ai laissé ce nom parce que dans quasi tous mes entretiens il revenait, et que c’est très développé. Dans mon manuscrit on peut mieux le voir, c’est appelé comme cela parce que, en fait, c’est une dénaturation forte du kernel Linux avec un ajout de beaucoup de couches qui vont dans tous les sens, c’est pour cela que, à un moment, la communauté va l’appeler frankenkernel. Ce kernel-là est donc spécifique à des SoC de vendeurs et au matériel de chaque téléphone.

Au dessus de ces frankenkernel, on a une première couche de l’OS Android qui est l’Android Open Source Project Cette couche-là n’est pas tout à fait au-dessus du frankenkernel, parce que, en fait, c’est une couche qui n’existe pas en soi, n’est possible à installer que dans les émulateurs et non pas sur des téléphones précis. Elle n’a pas de spécifications par rapport au SoC [ou au matériel présent dans un téléphone donné, Note de l’intervenante] on va voir plus tard ce que cela veut dire. C’est une couche totalement libre, totalement open source, et, au-dessus cette couche-là, on va avoir la vraie version de l’OS Android qui va être sur un téléphone, on va avoir l’AOSP adapté à ce frankenkernel-là avec les pilotes de tous les SoC, et aussi avec tout ce qu’il faut pour faire marcher les écrans, tout le matériel du smartphone et c’est donc l’OS final qui va se retrouver sur un téléphone.

Pas un Android unique mais une version Android par appareil

On n’a pas un Android, un système d’exploitation, mais on a un système d’exploitation Android par appareil. On l’a appris en parlant notamment avec Marvin Wissfeld, au cours des entretiens, qui nous a dit qu’AOSP n’est pas déployable sur du matériel physique, il ne fonctionne que sur des émulateurs, et, pour chaque modèle de smartphone, il faut une version d’Android sur mesure qui intègre les drivers – les pilotes –, les firmwares spécifiques au SoC, à l’écran, etc., aux composants précis du modèle.
Ça laisse présager que pour chaque téléphone il faut une version d’Android et pour chaque version d’Android on a cette imbrication de couches, ce que j’ai montré tout à l’heure. Ça laisse présager une complexité et un besoin de rigueur dans la manière de faire les mises à jour, quand il y aura des mises à jour dans les différentes couches de ces logiciels.
Vous imaginez bien, par exemple, que quand Linux kernel est mis à jour, il faudra que ce soit mis à jour aussi dans l’Android common kernel, dans le frankenkernel par les fabricants de Soc, et qu’ensuite ce soit pris en compte au-dessus [dans l’OS développé par Google et la couche de l’OS ajoutée par le fabricant de téléphone, Note de l’intervenant].
On l’a aussi dans l’autre sens, c’est-à-dire que ça va un peu dans les deux sens : lorsque Google décide de mettre à jour Android,tous les ans on a une nouvelle version d’Android, il faut aussi que les anciens frankenkernels soient compatibles avec le nouvel Android, donc qu’il puissent faire une mise à jour vers cette version d’Android.
Au centre de cela on a en fait les fabricants de SoC et de frankenkernels qui doivent se tenir à jour des mises à jour du Linux kernel, mais aussi des nouvelles versions Android de Google, s’ils veulent que les téléphones contenant ces SoC soit mis à jour.

On va voir que ça ne va pas se passer comme cela. Il ne va pas y avoir des mises à jour du frankenkernel, et qu’il va plutôt n’y avoir que des ruptures de mise à jour.
Je ne vais pas en parler en détail mais je vais prendre, pour illustrer l’exemple, de deux téléphones qui portent le même SoC, un Motorola et un Fairphone 3, Fairphone étant une des entreprises avec lesquelles j’ai discuté dans mes entretiens, et je vais montrer comment se passent dans la pratique, sur ces téléphones-là, les ruptures de mise à jour. Vous suivrez bien dans le manuscrit, avec cette illustration [diapositive 36], là ce serait trop complexe à voir en totalité.

L’obsolescence en action

En tout cas, on a comme résultat que lorsqu’un modèle de téléphone sort, souvent il a déjà trois ans de retard sur le kernel Linux, parce qu’il faut un an à Google pour développer son ACK et, en général, un ou deux ans aux fabricants de SoC pour faire leurs frankenkernels, on a donc déjà trois kernels Linux de retard car là aussi une nouvelle version du kernel Linux sort tous les ans. Mais, de toute façon, les téléphones ne sont jamais mis à jour pour les nouveaux Linux kernels, ça n’arrive jamais, même s’ils n’avaient pas de retard, cela ne changerait pas, en pratique ça n’arrive pas, donc ils auraient, de toute façon, du retard.
Les frankenkernels sont mis à jour au niveau des patchs de sécurité du noyau qu’ils portent, parfois, pas toujours, pas à chaque patch de sécurité, et ça dure pendant un an ou deux au maximum et, ensuite, on remarque qu’on a un arrêt du support souvent silencieux. Ce silence-là est embêtant, parce qu’on voit beaucoup, dans les forums d’utilisateurs, une incertitude des personnes qui ont un modèle de téléphone et qui ne savent pas ce qui va se passer, elles n’ont pas nouvelles, elles devinent, elles demandent, mais elles n’ont pas de réponse sur les mises à jour ou pas de leur OS et donc la fin d’envois de support logiciel ou pas de leurs téléphones. Parfois on a des déclarations de presse selon lesquelles il va y avoir des mises à jour mais, parfois ça ne se passe juste pas, parfois oui. Il n’y a pas de transparence, il n’y a pas d’obligation de transparence, pas de suivi rigoureux non plus, de ce support par les fabricants et vendeurs de téléphones.

L’obsolescence en action : ruptures de rétrocompatibilité

Pareil, je ne vais pas tout expliciter là, mais je montre, dans mon manuscrit, à quels endroits on a les ruptures de rétrocompatibilité : quand une nouvelle version soit au niveau de l’Android OS soit au niveau du ACK, on ne va pas avoir toujours la possibilité de mettre à jour, même si on le voulait, le frankenkernel du téléphone, c’est-à-dire que la nouvelle version va casser la rétrocompatibilité avec le kernel d’avant ou la version d’avant de l’OS. C’est plus grave parce que, du coup, même si on le voulait on ne pourrait pas ou très difficilement.

Dans mon travail, j’ai aussi suivi quelques alternatives libres et quelques entreprises qui le font quand même, qui vont parfois au-delà de ces ruptures-là, notamment Fairphone qui arrive à mettre à jour malgré le fait qu’il y ait une rupture de rétrocompatibilité une première fois du fabricant de SoC Qualcomm, une deuxième fois de Google avec Android. Ils y arrivent jusqu’à un moment où ils disent « là c’est trop, Google a fait trop de changements, on n’y arrivera pas, c’est trop de travail. On n’a plus ce temps [et ce savoir, Note de l’intervenante], on va arrêter là. »
LineageOS, qui est un système alternatif, va aller au-delà, faire plusieurs mise à jour, jusqu’à Android 15, puis, à un moment, eux aussi vont dire « non, là on ne peut plus – je l’explique bien dans le manuscrit –, les différences sont trop grandes pour qu’on puisse avoir de la force vive pour développer la mise à jour vers Android 16 sur le Fairphone 3. »

Ruptures de maintenance : anti-patterns de développement chez les vendeurs

Pourquoi a-t-on ces ruptures de maintenance ?
J’ai essayé de creuser un peu avec les développeurs ce qui fait qu’au niveau du code on n’arrive pas à mettre à jour [car le code des frankenkernels ayant hérité de la licence GPL du kernel est libre et disponible, Note de l’intervenante].
On remarque qu’on a, en fait, beaucoup d’anti-patterns au niveau du développement dans ce code-là.
Tous les développeurs m’ont dit que quand on est basé sur le kernel Linux, si on ne mainline pas, si on ne suit pas la ligne de développement et de mises à jour du kernel Linux, il est plus difficile de suivre les mises à jour plus tard. C’est-à-dire que les distributions basées sur Linux suivent, en général, la ligne du kernel [elles font du mainlining], ce qui fait qu’on a souvent des petits changements à faire, des petites mises à jour. Si les mises à jour s’accumulent, elles deviennent de plus en plus grandes, ça devient de plus en plus difficile, voire impossible, de les faire.
Dans les frankenkernels on a en outre beaucoup de spaghetti code, je peux l’expliquer plus au moment des questions, et autres anti-patterns de code.
On a du code fermé, du manque de documentation, des schématiques de fonctionnement fermées pour des matériels qui changent très souvent et qui ne sont pas standardisés.
Or, les recherches montrent, que dans les logiciels, libres ou pas, dans tous les logiciels, que la documentation, l’accès au code et l’évitement des anti-patterns sont ce qui permet une bonne maintenance logicielle.

Discussion

On rentre maintenant dans la phase discussion.

Dette technique et transfert de la responsabilité de maintenance

On a une dette technique qui se crée dans Android à différents niveaux.
Là, je ne l’ai pas mise mais, la première des techniques, quand Google met à jour Android, il met à jour les ACK et, en fait, il laisse la dette technique de mettre à jour les frankenkernels aux fabricants de téléphones. Il ne fait pas de suivi, il s’en fiche s’ils ne le font pas, il fait ses propres mises à jour et il se fiche du reste. Mais quand il fait ses mises à jour, il empêche des rétrocompatibilités et là aussi il s’en fiche, il ne pense qu’à son produit en quelque sorte.

Une autre dette technique qui se crée ainsi est due au fait qu’on utilise des logiciels libres dans Android, le noyau Linux par exemple, parce que ça permet un développement rapide et une mise sur le marché rapide de nouveaux produits, ce qui intéresse beaucoup les vendeurs, mais, ensuite, Google et les vendeurs mettent très peu d’efforts dans la maintenance du kernel ou alors pour faire un retour de code propre Android à Linux. On a accaparement et une création de dette technique : on utilise les logiciels libres, mais on n’y contribue pas en retour. Et on a ainsi un transfert de la charge de la maintenance vers les communautés de ces logiciels libres, et cela a été étudié dans la recherche.

Double standard de mises à jour par Google

On remarque aussi un double standard de la part de Google sur les mises à jour. C’est vraiment quelque chose qui ressort dans les entretiens avec LineageOS [6], Marvin [Wißfeld] et MicroG [7], donc deux systèmes alternatifs, qui nous disent que dans AOSP, qui est la couche open source d’Android, en fait on a des applications qui sont vieilles d’il y a dix ans, qui ne sont pas mises à jour, parce qu’on met à jour leur équivalent mais dans la version Google OS propriétaire qui doit être clinquante [qui est celle qu’on vend aux fabricants de téléphones, Note de l’intervenante].
Parfois on a. dans AOSP. des abandons d’applis essentielles. Par exemple, dans Android 14, Google abandonne les applis de messagerie et d’appel, tout simplement, il n’y a plus « Messages » et « Appels » dans AOSP et cet abandon avait été découvert par des développeurs, par hasard, dans une ligne de code Google, en commentaire.
Et on a des services essentiels de l’OS qui sont verrouillés par Google, notamment au niveau des Google Play Services, qui sont vraiment très importants dans le fonctionnement d’Android. En faisant en sorte que ces services essentiels de l’OS soient dans ses mains [dans la partie propriétaire d’Android et non pas dans AOSP, Note de l’intervenante], Google fait en sorte que tout le monde mette la version propriétaire de l’OS de Google sur les téléphones Android, avec les applis obligatoires de Google et les services Google Play.

Ouverture/fermeture d’Android

Du coup, un point de discussion apparaît ici, sur la vraie/fausse ouverture d’Android.
Google se vante, depuis le début, qu’Android est un système ouvert, open source, qui va pouvoir profiter à tout le monde, etc. C’est vrai que beaucoup de vendeurs se sont emparés d’Android, mais :

• Le développement d’Android, y compris de sa partie AOSP, se fait soit en fermé soit de plus en plus en interne
• Les accords contractuels avec les vendeurs les obligent à mettre par défaut sur leurs téléphones un Android googlisé, avec les produits Google propriétaires.

Avant en Europe, je ne sais pas dans les autres pays, il y avait une clause qui empêchait l’installation d’OS alternatifs dans toute la gamme de smartphones d’un vendeur s’il avait passé un contrat avec Google. Il y a donc eu un procès pour abus de position dominante contre Google par l’Union Européenne. Google n’a depuis plus le droit de faire ça, mais il agit autrement maintenant sans que cela change dans les faits. Il y a de nombreux procès pour ce genre de comportement anticoncurrentiel et d’abus de position dominante dans tous les continents en ce moment par rapport à Google [Royaume-Uni, États-Unis, Japon, Inde].

On a ici un phénomène, je l’ai dit tout à l’heure, qui est l’accaparement des logiciels libres pour développer un logiciel qui, finalement, va être fermé, avec mainmise d’un acteur Big Tech, par différents moyens qui sont techniques, mais pas que, aussi légaux ou contractuels. Ekbia et Nardi parlent eux de phénomène d’hétéromation [dans le chapitre 4, nous parlons, avec Jeanne Guien, d’enclosure logicielle, Note de l’intervenante].

Stratégies de maintenance dans Debian

Sans transition, nous allons passer à une étude de cas un peu plus joyeuse parce que là on a vu qu’on avait beaucoup de problèmes – fermeture, manque de mises à jour, obsolescence, etc. Nous allons un peu étudier la maintenance. Est-ce qu’on a des stratégies pour faire de la maintenance quand même ? Est-ce qu’il y a des cas où ça marche, comment ça marche, quels sont les freins et quelles sont les choses qui fonctionnent mieux ? Pour cela nous allons nous pencher sur Debian.

Introduction à Debian OS

Pourquoi Debian ? Parce que c’est aussi basé sur le noyau Linux, comme Android, mais cette fois on n’a que des logiciels libres.
Cet OS a plus de 30 ans, une communauté de plus de 1500 développeurs bénévoles dans le monde entier.
C’est utilisé sur de nombreux serveurs, supercalculateurs, microcontrôleurs, c’est peut-être le système supportant le plus d’architectures aujourd’hui.
Et il est à la base d’un grand nombre de distributions Linux dérivées, au moment de l’écriture du manuscrit de thèse c’était 210 distributions dérivées, j’ai mis quelques noms de distributions très connues qui sont toutes basées sur Debian [Ubuntu, Kali Linux, Tails, Rasbian, etc.].

Bien plus qu’un OS, une communauté autour d’un projet et de valeurs communes

Debian est plus qu’un OS, c’est une communauté autour d’un projet avec des valeurs communes.
Il y a une philosophie de Debian qui consiste en un ensemble de règles et de guides qui régissent la communauté avec des principes forts, des licences d’ouverture, la contribution dans le monde des logiciels libres, la diversité de Debian, le code de conduite. Il y a aussi des guides techniques, c’est très riche.
Gabriella Coleman [8] a fait un travail remarquable en ethnographie dans Debian. Dans les années 2005/2010, elle a vraiment fait émerger la communauté, elle a écrit plusieurs choses autour des valeurs éthiques de Debian, comment le projet est structuré, comment est structurée la communauté. Elle a parlé d’enculturation éthique, j’aime beaucoup, c’est quand les personnes s’intègrent et commencent à intégrer la communauté. La lire a donc été vraiment très important pour moi parce que j’avais tout un univers qui était très bien décortiqué. Je connaissais déjà un peu la communauté, mais son point de vue est très intéressant. Elle montre aussi comment, à travers ses valeurs éthiques, Debian se reconfigure en permanence depuis 30 ans mais reste soudé autour de ses valeurs, même si ça bouge et même si elles sont discutées lors de débats dans la communauté.

Un OS fait de paquets

C’est un OS qui est fait de paquets. Dans Debian, la plus petite unité de code c’est un paquet, c’est une unité de code importante. Ce sont des entités dynamiques qui suivent un cycle de vie de production et maintenance, cela a été étudié par Nguyen et Holt.
Les paquets dépendent les uns des autres dans le système global de Debian. Du coup, on a des dépendances entre les paquets et on a un système de management des paquets qui est très important parce que c’est ce qui va permettre de clarifier les dépendances entre les paquets, notamment au moment de leur mise à jour.
Il y a eu beaucoup d’études et d’équipes de recherche qui ont travaillé sur ce système de management des paquets Debian. J’en ai cité quelques-unes. Ça a été un champ de travail important : on améliore constamment le système de management des paquets, ce qui, finalement, sert à une bonne gestion de la release, la version stable de Debian qui sort tous les deux ans et qui est utilisée sur les ordinateurs et de sa maintenance via les mises à jours dont cette release va bénéficier.
Dans mon travail, j’ai pris deux cas d’étude de la maintenance dans Debian : les paquets et le programme Long-term support [LTS] qui est en fait le programme de support garanti à cinq ans de chaque version de release stable de Debian, j’en parle plus en détail dans le manuscrit.

Questions de recherche

Les questions de recherche tournent autour de la maintenance, la façon dont elle est faite, je l’ai dit tout à l’heure, sans le montrer. Quels sont les freins ? Quelles sont les barrières ? Qu’est-ce qui la favorise ? On remarque, dans cette maintenance, la façon dont elle peut aider à améliorer notre vision de la maintenance logicielle et remédier à l’obsolescence plus largement que juste dans Debian.

Méthodologie

La méthodologie est un tout petit peu différente parce que le travail d’ethnographie est plus grand.
J’ai eu des entretiens semi-structurés. L’ethnographie a été faite lors de rencontres avec la communauté que j’ai suivie pendant un an, un an et demi. J’ai collecté toutes sortes de données pendant ces rencontres-là, les données de terrain sont ainsi beaucoup plus riches que le cas d’étude d’Android.

Entretiens et discussions informelles

Là ce sont 17 entretiens, mais il y a aussi des discussions informelles importantes que j’ai eues pendant les rencontres.

Ethnographie dans la communauté

Là ce sont les quatre événements communautaires dans lesquels je suis allée. Chacun a eu un rôle un peu différent dans ma recherche, je ne vais pas les détailler là. C’est surtout celui de Berlin [MiniDebCamp], en 2024, qui a été très long et complet, où j’ai pu suivre à la fois des sessions de travail et, à la fois, la conférence habituelle avec toutes les présentations publiques.

Recherche documentaire

La documentation analysée a été assez technique, encore une fois, surtout centrée sur Debian, avec les forums, les sites communautaires et officiels de Debian, les mailing-lists ou forums internes de la communauté Debian.

Analyse des données

J’ai fait une analyse thématique de toutes mes données et surtout des entretiens.
Il y a eu aussi deux ateliers de travail participatif pendant la miniDebCamp de Berlin qui m’ont aidée à comprendre comment fonctionne un paquet en travaillant avec l’équipe dédiée, j’ai mieux compris comment un paquet se construit et se maintient. Il y a eu deux exemples :

• le premier : produire un paquet qui n’existe pas encore
• le deuxième : maintenir un paquet qui n’est plus maintenu.</li

J’ai fait une analyse des entretiens, pareil, avec une transcription, des citations choisies et remises en contexte. Comme dans le cas d’Android plus haut.

Résultats : Analyse thématique

Du coup, les résultats. On va entrer dans le détail de cette analyse thématique et de ce qu’elle a permis d’identifier : la maintenance dans Debian, les facteurs qui favorisent la maintenance et les facteurs qui sont des freins à la maintenance.

La maintenance dans Debian

On commence par la maintenance dans Debian.
Premier résultat qui ressort c’est que la communauté Debian est structurée autour du travail de maintenance.
Cette maintenance est localisée à la fois au niveau technique mais pas que. On va avoir plein d’endroits non techniques où elle va être localisée, que j’ai représentés avec les plus grands losanges :

• la maintenance sociale, au niveau social : les relations dans la communauté entre les personnes, entre les développeurs
• la maintenance des processus de travail, très importants. Le travail va être organisé, avec des teams, des équipes, tout est organisé en équipes, il y a à peu près 200 équipes dans Debian. On va avoir des procédures, mais aussi des rôles, les personnes vont avoir des rôles différents selon leurs connaissances et leur entrée dans la communauté. Par exemple, le rôle de mentor pour aider les personnes qui connaissent moins ou qui savent moins faire avec les paquets, les aider à apprendre et faire avec elles. Ensuite ces personnes vont pouvoir, en quelque sorte, monter en grade et devenir mainteneurs de paquets, développeurs de Debian, développeurs sponsors, etc. Le fait de changer de rôle donne aussi des droits supplémentaires ;
• on va voir la maintenance technique, évidemment, c’est du code, c’est un OS, donc on va avoir le travail pour faire les paquets, le travail pour faire les releases. Ressortent ici des choses qui ont été faites qui semblent importantes à la communauté : les reproductible builds faire en sorte que les paquets Debian soient reproductibles ;
• on a aussi un travail important au niveau de l’infrastructure, la maintenance de l’infrastructure. Debian est un grand projet avec beaucoup de membres dispersés dans le monde, du coup il y a besoin d’avoir une infrastructure physique mais aussi sociale. On a les serveurs, les logiciels, la documentation, qui va beaucoup servir à tout ce monde pour se mettre d’accord, pour travailler ensemble, pour se rencontrer, etc.

Ça ce sont les points principaux qui structurent la maintenance.

La maintenance des processus de travail dans Debian

J’ai détaillé dans le manuscrit évidemment et sur ce schéma [diapositive 53] on peut voir les détails, mais je n’aurai pas beaucoup de temps aujourd’hui pour revenir longtemps dessus.
Là, par exemple, j’ai eu un entretien avec un développeur junior de Debian qui me racontait le processus parce qu’il y a des processus de travail, comment on devient mainteneur. Pour le devenir, il y a vraiment un processus très clair, très transparent, qui est documenté, qui est mis en place dans l’application manager, qu’on applique pour devenir mainteneur et on a un manager attitré.

Les facteurs favorisant la maintenance

Maintenant, si on se plonge dans les facteurs qui favorisent la maintenance, on va trouver un peu les mêmes thématiques, des facteurs qui favorisent et d’autres qui freinent.
Dans les pratiques sociales, quelque chose qui semble très important c’est la relation des développeurs de paquets Debian avec le paquet qui est à la base de ce paquet-là. C’est-à-dire que si, dans Debian, vous avez envie de mettre LibreOffice, par exemple, le développeur principal de LibreOffice va devoir travailler avec vous pour pouvoir intégrer LibreOffice dans Debian, ou plutôt le développeur du paquet Debian va devoir travailler avec l’upstream pour rendre le travail plus facile des deux côtés, parce que c’est dans l’intérêt des deux. En fait, si on remarque un bug dans Debian, il faut aussi qu’il soit résolu dans LibreOffice et inversement, pour que, à chaque fois qu’on a une mise à jour, on n’ait pas à refaire les mêmes choses dans le paquet. Il y a des choses qu’on fait petit à petit, à chaque mise à jour.
Cette relation-là est très importante, à savoir que s’il n’y a pas cette relation-là un paquet va mourir, on va le voir dans les barrières.
Il y a aussi tout un tas de rôles dans Debian sur la diversité, l’inclusivité, le fait de se rencontrer en personne, d’avoir des élections, d’avoir de la transparence, maintenir cette communauté un peu de cette façon.
Il y a des pratiques de maintenance qui ressortent qui sont utiles, il y a les reproducible builds qui font apparaître des bugs qui n’apparaissaient pas autrement.
La collaboration upstream est très importante, cela ressort dans la maintenance technique aussi. La réputation de Debian aide cette collaboration, c’est-à-dire que les gens collaborent plus facilement sur les paquets Debian. Debian est une distribution importante et réputée.
L’archivage du logiciel est apparu. Un développeur a cité Software Héritage [9] comme étant un moyen, en fait, pour l’aider pour trouver les licences des paquets et, à la fois, l’aider à trouver l’origine du code qu’il avait perdu ou qu’il cherchait, je ne sais plus pourquoi, je ne me souviens plus du contexte, c’est dans le manuscrit.

On a aussi des boosts organisationnels, des facteurs qui aident dans l’organisation du travail. Par exemple, le fait d’avoir des équipes, mais aussi des procédures, je l’ai dit, et aussi d’avoir des façons codifiées de faire les choses. Par exemple, si on a besoin de faire un nouveau paquet, on va poster une issue qui s’appelle request for package [RFP]. C’est donc très codifié : il faut écrire à tel endroit, il faut ouvrir un bug à tel endroit. Du coup toute la communauté sait qu’il y a une demande pour ce paquet-là et si on veut le packager, on va faire ensuite un ITP [Intent To Package], donc la communauté saura, à tout moment, quel est l’état de ce paquet-là et quel travail est en train d’être fait dessus [en suivant la trace de ces évènements sur le paquet, Note de l’intervenante].

Enfin, autre facteur favorisant la maintenance, un système financier très original a été mis en place sur Debian pour récolter des fonds des entreprises pour pouvoir faire cette maintenance de la version stable, la LTS, Long Term Support, sur cinq ans dans Debian. Ce système assure aussi une neutralité dans le travail de maintenance, c’est-à-dire que les entreprises n’auront pas leur mot à dire sur quel paquet on maintient en priorité ou pas [non-ingérence de la part des entreprises]. C’est la communauté qui décide. Ce financement de la LTS, qui a été mise en place par Freexian dans Debian, est très original, je l’explique dans le manuscrit plus en détails.

Les freins à la maintenance

Les freins maintenant.
Ce qui ressort comme étant parmi les freins le plus importants, ce sont les freins techniques, ce sont des freins dus à la bureaucratie, parce que c’est une communauté qui vieillit, il y a des infrastructures qui vieillissent, il y a, par exemple, des documentations qui sont incohérentes parce qu’elles sont multiples et entraînent de la confusion, ça ressort souvent. Moi-même je l’ai vu, il y a des sites qui parlent plusieurs fois, de différentes façons, d’une même chose. Mais ce qui apparaît vraiment comme étant le problème qui inquiète le plus, c’est le problème social et humain.

[Problème de son de la part d’une des personnes en ligne]

Ce qui va inquiéter aussi la communauté ce seront les problèmes sociaux et humains.
Il s’agit ici de prévenir et éviter le burn-out, comment faire avec une communauté qui vieillit et comment faire pour attirer de nouvelles personnes. C’est revenu plusieurs fois et ça semblait assez préoccupant dans le sens où on cherchait des solutions, mais on n’avait pas forcément des réponses.

Discussion

Il y a juste une diapo ici sur la discussion.
Les trois choses les plus importantes que j’ai retenues de cette étude :

• la maintenance dans Debian a des répercussions positives sur la maintenance dans les logiciels libres à l’extérieur de Debian ;
• la maintenance dans Debian est un processus collaboratif et collectif aussi avec le monde à l’extérieur, plus large, comme on l’a dit juste avant ;
• une autre découverte, très intéressante, c’est que la maintenance dans Debian ne consiste pas à imposer des mises à jour, il s’agit d’un processus visant à déterminer ensemble comment mettre en œuvre ces mises à jour sans causer de préjudice, discuter et prévoir comment les faire au mieux pour qu’il n’y ait pas des ruptures par exemple de rétrocompatibilité ou des choses graves. C’est quelque chose qui change totalement de la façon habituelle qu’on a de voir les mises à jour, quelque chose qu’on nous impose, quelque part, et qui est fait.

L’obsolescence, modèle économique du capitalisme numérique

J’avais prévu de ne pas parler en détail de ce chapitre que j’ai coécrit avec Jeanne Guien, qui est le dernier chapitre [chapitre 4] dans la thèse, et qui parle de l’obsolescence en tant que modèle économique du capitalisme numérique, parce qu’il existe en français, en anglais et il va à priori être publié en partie dans un livre à venir.
L’idée, ici, c’était vraiment de repartir des travaux de Jeanne Guien, d’y insérer mes travaux sur les logiciels et le matériel, et de voir comment l’obsolescence s’impose comme un modèle économique, une stratégie d’organisation de l’industrie informatique. On revient, dans ce travail, sur le processus de miniaturisation, sur la loi de Moore [vue par le chercheur Sacha Loeve, qui la lit comme une règle et non pas une loi que l’industrie suivra pour la planification de la production informatique, Note de l’intervenante]. Ensuite on revient sur quelque chose que j’ai beaucoup aimé faire qui est la perspective historique de l’existence du logiciel en tant qu’entité séparée du matériel, avec ce qu’on a appelé le software unbundling, que je vois comme une première étape vers ce que j’ai appelé l’enclosure logicielle, qu’on explique aussi dans le chapitre.

On a aussi, dans ce chapitre, une brève analyse de l’obsolescence dans le nuage, c’est plus actuel, avec la notion de « nuagification » et des effets comme la connexion permanente, la jetabilité des données et l’obsolescence des infrastructures, [maisaussi de l’enshittification, emmerdification des services, concept introduit par Cory Doctorow [10] journaliste canadien, Note de l’intervenante].

Conclusion

J’en suis à la conclusion.
On voulait, dans ce travail de recherche, analyser l’obsolescence, identifier les facteurs qui la font et qui créent des ruptures de maintenance logicielle.
On a identifié des facteurs techniques que je vais citer en vrac :

• interruption silencieuse du support logiciel
• absence de mise à jour et de mise à niveau
• offuscation du code
• code propriétaire et binaire
• manque de documentation
• schémas fermés
• anti-patterns dans les pratiques de codage, particulièrement le cas chez les fabricants de SoC et de smartphones dans l’écosystème Android.

De l’autre côté on a aussi des facteurs socio-économiques, pas juste techniques, soutenus par des instruments techniques, juridiques, contractuels qui créent des dynamiques de pouvoir et d’abus de pouvoir au sein des écosystèmes logiciels et c’était le cas par exemple de Google dans l’écosystème Android.

Dans les facteurs de remédiation, on a souligné l’importance des pratiques de développement de logiciels libres/open source pour une maintenance plus forte.

L’étude met en évidence les pratiques de codage qui constituent des stratégies de maintenance importantes au niveau du développement. Là j’ai cité le mainlining et l’upstreaming, mais, à la fin de mon manuscrit, j’ai vraiment une liste précise de toutes ces pratiques-là dont les développeurs m’ont dit leur importance pour faire de la maintenance et qui ressortent de l’étude.

De l’étude de Debian, je retiens que c’est l’acte collectif de maintenance, les interactions sociales au sein de la communauté qui développe le logiciel, et aussi avec les communautés externes, qui sont essentielles pour une maintenance à long terme, mais qui ont aussi une résonance extérieure dans la maintenance logicielle plus globale.
Et comme le montrent les pratiques de maintenance chez Debian, une maintenance logicielle n’est pas juste une application de mises à jour, c’est un processus social : on prépare les mises à jour, on les discute, on les analyse et on voit si elles répondent aux besoins de la communauté des utilisateurs, si elles causent, ou pas, des perturbations, des problèmes de compatibilité et, si elles en causent, comment on fait pour qu’elles en causent le moins possible, quitte à ne pas les faire. C’est vraiment quelque chose de très beau à voir, que j’ai pu voir dans plusieurs exemples et qui est intéressant à découvrir en tant que pratique sociale.

Je retiens quelque chose de positif qui est que l’obsolescence n’est pas inévitable même si, souvent, elle est présentée comme telle ou, trop souvent, on a des exemples qu’elle est planifiée comme telle.
L’exemple de Debian et celui des systèmes mobiles alternatifs libres le montrent.
On peut développer des logiciels pour des appareils durables, on connaît des stratégies permettant d’y parvenir et elles sont discutées au sein des communautés qui les mettent en place et qui essaient de les améliorer.

Merci.

Organisatrice : Merci Eda. Je vais donner la parole au jury à distance.