Group items tagged

Open Badges, le standard ouvert pour la reconnaissance des apprentissages, a prouvé la puissance d’une technologie simple, abordable, résiliente et digne de confiance pour créer un écosystème de reconnaissance ouvert fonctionnant à travers les pays, les secteurs éducatifs, l’emploi, les environnements sociaux et les technologies.

Les badges numériques ouverts ont démontré que nous avons les moyens et la possibilité de mettre fin aux disparités du paysage de la reconnaissance. En reliant et en nourrissant les référentiels de compétences, ils deviennent les éléments constitutifs d’une architecture ouverte pour la reconnaissance des apprentissages tout au long de la vie. Ils créent les conditions pour que les individus aient le contrôle de leur propre reconnaissance, pour fonder leur identité et leur capacité d’agir en toute autonomie, que ce soit formellement (au sein des institutions) ou informellement (à travers les communautés).

Le libre accès à la connaissance et à l’éducation est largement reconnu comme un facteur irremplaçable de croissance sociale et humaine et un élément indispensable pour consolider et enrichir la citoyenneté, capable de donner aux citoyens les compétences nécessaires pour relever les défis du nouveau millénaire, ainsi que la conscience de valeurs partagées et de l’appartenance à divers espaces sociaux et culturels.

La création d’un espace ouvert pour la délivrance et la reconnaissance de l’apprentissage tout au long de la vie et à vie est un facteur clé pour la promotion de l’inclusion sociale, l’employabilité et la mobilité des citoyens du monde, et le développement de notre planète. En fin de compte, la capacité de reconnaître ses apprentissages, sociaux ou professionnels, est un facteur clé dans la construction de la capacité d’agir en toute autonomie et dans l’établissement de la confiance au sein d’une communauté.

Nous devons maintenant étendre ce travail au-delà des frontières de l’enseignement supérieur, pour créer un continuum au travers de tous les apprentissages, tout au long et dans toutes les dimensions de la vie. Ceci pourra être obtenu en encourageant l’adoption d’unités de valeur plus ouvertes pour représenter et partager les acquis d’apprentissage, que ce soit dans des contextes formels, informels ou non-formels.

Avec mes collègues Léa Macias et Samuel Huron, nous avons inventorié une centaine d’applications et de plateformes construites ces 8 dernières années. Celles-ci proposent des services très variés : Information-service, mise en relation, recherche d’emploi, hébergement, traduction, apprentissage des langues, éducation et formation, identité, santé… Nous avons constaté que ces applications ont une vie de comète : ainsi en juin 2018, 27 % des applications recensées précédemment avaient disparu (13 sur les 48 recensées). En septembre 2018, 29 % avaient disparu (soit 10 sur les 35 recensées).

Nous avons aussi testé ces applications avec des réfugiés inscrits à l’école Simplon, dans le programme Refugeek qui les forme à être programmeurs en France. Ce sont des gens habitués au code, aux applications. Dans leur téléphone, nous n’avons trouvé aucune application destinée aux réfugiés. Ils utilisent Facebook, WhatsApp, Google, comme tout le monde

Nous avons aussi constaté que toutes les applications, même les plus simples, demandaient des informations personnelles. Toutes ont l’idée de faire reposer leur modèle économique sur les data. C’est classique dans le champ des applications. Mais quand on travaille avec des réfugiés, c’est délicat. Car ces personnes ne sont pas réfugiées par hasard : elles fuient des dangers et il faut faire très attention avec ces données.

Les applications qui marchent, comme CALM (Comme à la Maison, application qui met en lien des réfugiés avec des particuliers qui peuvent les héberger pour des durées variables, ndlr), c’est parce qu’elles mettent en pratique une idée longuement mûrie, dans le cas de CALM celle de favoriser l’intégration par l’immersion.

CALM, développé par le mouvement citoyen Singa , repose sur l’idée de l’intégration par l’immersion. je crois aussi que c’est très efficace. Les codes d’une société s’acquièrent plus facilement lorsqu’on est immergé dans un environnement, on approche l’altérité différemment. Surtout, des sentiments naissent de cette mise en relation de reconnaissance, de satisfaction... Cela crée une énergie très positive. Parfois ces relations durent quelques semaines, parfois toute une vie. Quand les migrants racontent des trajectoires migratoires réussies, il y a toujours une personne, à un moment donné, qui les a tiré vers la société. Singa a essayé de capter ce moment, de l’investir de manière numérique et je pense que c’est une bonne chose.

Ensuite, nous avons vu que l’hospitalité ne pouvait pas être déléguée à des techniques de matching. L’hospitalité, ce n’est pas Tinder. Nous avons essayé d’utiliser le matching pour organiser des rencontres, par exemple, sur la base d’intérêts communs. Mais ça ne marchait pas. Ou bien, quand ça prenait, les gens passaient sur Facebook, qui donne un aperçu plus complet de l’environnement social de la personne... Mais CALM reste une plateforme importante. Elle a été beaucoup médiatisée et a permis d’ouvrir les esprits, de faire parler de l’hébergement chez soi. Je pense qu’elle n’est pas étrangère à l’amendement adopté en octobre 2018 par l’Assemblée Nationale, instaurant un crédit d’impôt pour les personnes hébergeant des réfugiés chez elles .

Dans le cas des véhicules autonomes en revanche, une vaste étude a été réalisée sur plusieurs années par le MIT Lab. Elle a concerné des millions de personne dans 233 pays (à travers le petit jeu http://moralmachine.mit.edu/) et a montré à quel point le traitement des questions éthique est variable, même lorsqu’on parle de conduite automobile ! Comme le relate Hubert Guillaud : « la question éthique diverge selon la culture, le niveau économique et la localisation géographique ; bien plus que selon des préférences individuelles (…) les Japonais ont plutôt tendance à préférer des véhicules qui épargnent les piétons alors que d’autres cultures, comme la culture chinoise, préfèrent des véhicules qui épargnent les passagers. » L’objectif d’une telle étude est d’apporter l’éclairage de la société toute entière afin que le système technique réponde au « bien commun ».

A l’initiative de Grégoire Japiot (@gregoire) et Matteo Mazzeri (@matemaz), le projet GEnIAL (voir le site internet) est « Une plateforme qui utilise les interfaces conversationnelles et l’intelligence artificielle afin de permettre à la population d’un territoire de mieux vivre dans sa ville à l’ère de la Smart City en offrant des moyens simples pour accéder aux services des administrations et des autres acteurs de la région. » Le projet, qui se revendique de « Society in the loop », est d’utilité publique et censé resté « la propriété des citoyens », contrairement aux services d’assistants proposés par les géants d’internet. Les données collectées ne sont pas commercialisées et la vie privée reste préservée. Grégoire, le fondateur, précise que les concertations citoyennes sont au cœur du projet. L’idée : intégrer dans le service les retours de la société (citoyens, administrations/institutions publiques, chercheurs et acteurs économiques) en vue d’élaborer des modèles d’apprentissage utilisés pour construire une « intelligence artificielle concertée ».

Concrètement, GEnIAL Bot, est une « solution qui vise à permettre aux utilisateurs d’interagir avec l’ensemble des informations d’un territoire via des interfaces conversationnelles de type chatbot et assistant vocal. » Au lieu de devoir utiliser des moteurs de recherche pour identifier les différents sites où se trouvent les informations recherchées ou bien de devoir téléphoner aux services concernés, les utilisateurs peuvent interroger GEnIAL Bot en s’adressant en langage naturel et se laisser guider sous forme de conversations vers l’information. Pour la partie technologique, GEnIAL « dispose d’une convention de partenariat avec le CERN qui lui permet de concevoir avec les équipes les plus pointues, une intelligence artificielle éthique et explicable, dont les modèles d’apprentissage sont pensés de manière à refléter l’identité du territoire et intégrer un processus de concertation continue avec ses habitants. »

A une échelle très locale, le projet GEnIAL pourrait entrer dans ce qu’il convient d’appeler la « démocratie technique ». La formule que j’emprunte ici à Callon, Barthes et Lascoumes dans l’ouvrage fondateur Agir dans un monde incertain, Essai sur la démocratie technique (Seuil, 2011) désigne notamment les dispositifs par lesquels des profanes peuvent peser sur les modes de conception et de diffusion des sciences et des techniques. A l’évocation de la démocratie technique, on pense souvent aux grandes polémiques et controverses qui ont agité des sujets technoscientifiques comme les OGM, l’enfouissement des déchets nucléaires, ou encore les traitements contre le SIDA. Ce dernier cas a montré que l’intrusion des malades parmi les experts a pu conduire à améliorer les protocoles des laboratoires pharmaceutiques, alors très éloignés de leurs vies.

Si ces exemples peuvent paraître éloignés des questions relatives à l’intelligence artificielle, ils permettent d’entrouvrir une autre dimension de la démocratie technique. Par-delà la pure contestation ou modification a posteriori d’une technique existante, Callon, Barthes et Lascoumes décrivent un modèle de « co-production des savoirs ». Ce modèle postule que les non-spécialistes peuvent produire des connaissances à partir de leurs intérêts propres. Ils sont les plus à même d’entrevoir les risques d’un projet et de les faire reconnaître comme légitimes lors d’une étape de conception commune. Ce faisant, ils participent pleinement à la production des sciences et des techniques. Ce modèle suscite des critiques : on pointe le fait que des profanes ne seraient pas capables de s’exprimer sur un sujet technique, et que par conséquent, l’avis des experts serait toujours supérieur, de meilleure qualité, et devrait être pris en compte en priorité.

De nombreux contre-exemples viennent infirmer ces thèses. L’expérience prouve que si les conditions sont réunies, des personnes éloignées d’un sujet technique ou scientifique peuvent tout à fait construire des rapports de grande qualité et reconnus comme tels par les experts eux-mêmes. Ce fut le cas lors des controverses concernant les OGM il y a de cela une vingtaine d’années. Callon, Barthes et Lascoumes racontent également comment les amateurs contribuent à améliorer la connaissance scientifique dans de nombreux domaines, comme par exemple l’astronomie.

pourquoi ce traitement démocratique si spécial devrait-il se limiter à l’intelligence artificielle ? Une des raisons est sans doute que l’on pressent que son déploiement va changer le monde et susciter des controverses qu’il vaut mieux anticiper. N’oublions pas cependant que de nombreuses technologies numériques (ou non) changent le monde plus insidieusement et suivant des échelles temporelles qui nous les rendent « invisibles à l’œil nu ». Légitimement, on pourrait aussi poser la question démocratique à leur endroit[20].

Ce que la démocratie technique questionne, c’est non seulement l’aménagement du progrès, mais aussi sa définition. C’est-à-dire la direction donnée à la civilisation. Entraîner une intelligence artificielle – même avec la méthodologie Society in the loop – c’est déjà faire le choix d’une intelligence artificielle. Ce qui ne veut pas dire que ce choix soit mauvais. Pas plus qu’il n’est naturellement bon. Disons que c’est un choix parmi d’autres. Ce point chaud qui concerne la définition du progrès est et sera de plus en plus au centre de toutes les questions liant technosciences et démocratie.

Parallèlement, l’Université de Montréal a bâti une « Déclaration pour un développement responsable de l’intelligence artificielle[23] ». Cette déclaration décrit dix principes phares pour guider le développement de l’IA, parmi lesquels un « principe de bien être » ou encore un « principe d’inclusion de la diversité » (

Toutes les controverses techniques n’ont pas vocation à passer sous les fourches caudines de la démocratie, il existe une multitude d’autres échelons pour co-construire, réguler, interdire ou favoriser des systèmes. En témoignent les nombreuses villes qui se « défendent » contre AirBnb ou Uber puis qui finissent par utiliser les données que ces sociétés récoltent, à d’autres fins (des « arrangements » a posteriori[25]). Par ailleurs, c’est aussi dans les écoles qui forment les ingénieurs, designers et entrepreneurs de demain et bien sûr dans les entreprises elles-mêmes, dont certaines décident d’être plus soucieuses des effets générés par leurs activités, que l’avenir se joue

Bien sûr, ces quelques pages souffrent de nombreuses limites et à de multiples niveaux. A mon sens néanmoins, le fond de la question consiste (aussi) à savoir quelle « dose » de démocratie nous sommes prêts à mettre dans nos ambitions technologiques. Et en retour, dans quelle mesure les technologies que nous produirons permettront ou non à la démocratie de continuer d’exister[26].

Il est nécessaire de revenir à plus d’efficience, de « challenger » les besoins en matériel, de redéfinir ce qu’est la performance. Tant que l’on se satisfera de cette lenteur uniforme avec des solutions pour ne pas ralentir plus (comme l’ajout de matériel), nous n’avancerons pas. La dette technique, notion largement assimilée par les équipes de développement, n’est malheureusement pas adaptée à ce problème (on y reviendra). Nous sommes sur une dette de ressources matérielles et de mauvaise adéquation entre le besoin utilisateur et la solution technique. On parle ici d’efficience et non pas uniquement de performance. L’efficience est une histoire de mesure du gaspillage. L’ISO définie l’efficience avec comme domaine : Time behaviour, Resource utilization et Capacity. Pourquoi ne pas pousser plus ces concepts ?

Développez du code Java pour un serveur J2EE ou pour un téléphone Android, ce n’est pas pareil. Des structures spécifiques existent par exemple pour traiter des données en Android mais les structures classiques sont toujours utilisées. Les développeurs ont perdu le lien avec le hardware. C’est malheureux car c’est passionnant (et utile) de savoir comment fonctionne un processeur. Pourquoi : abstraction et spécialisation (nous verrons cela plus loin). Car en perdant ce lien, on perd une des forces du développement. Ce lien est important chez les hackers ou chez les développeurs d’informatique embarquée mais malheureusement de moins en moins présent chez les autres développeurs.

Les pratiques devops pourraient répondre à cette perte de lien. Là, c’est pareil, nous n’allons pas jusqu’au au bout : généralement le devops va se focaliser à bien gérer le déploiement d’une solution logicielle sur une infrastructure mixte (matérielle et un peu logicielle). Il faudrait aller plus loin en remontant par exemple les métriques de consommation, en discutant sur les contraintes d’exécution… plutôt que de “scaler” juste parce que c’est plus simple.

Certaines technologies ont une utilité mais sont maintenant systématiquement utilisées. C’est le cas par exemple des ORM qui sont devenus systématiques. Aucune réflexion n’est faite sur son intérêt en début des projets. Résultat : on a rajouté une surcouche qui consomme, qu’il faut maintenir et des développeurs qui n’ont plus l’habitude d’effectuer des requêtes natives. Cela ne serait pas un problème si chaque développeur connaissait très bien le fonctionnement des couches d’abstraction : comment fonctionne HIBERNATE par exemple ? On s’appuie hélas de façon aveugle sur ces frameworks.

Le besoin d’abstraction est lié à un autre défaut: nous attendons toujours des outils miracles. La silver bullet qui améliorera encore plus nos pratiques. Le langage idéal, le framework pour aller plus vite, l’outil de gestion miracle des dépendances… C’est la promesse à chaque fois d’un nouveau framework : gagner du temps en développement, être plus performant… Et on y croit, on fonce. On abandonne les frameworks sur lesquels nous avions investi, sur lesquels on avait passé du temps… et on passe au nouveau. C’est le cas actuellement des frameworks JS. L’histoire du développement est pavé de framework oubliés, non maintenus, abandonnés… Nous sommes les champions pour réinventer ce qui existe déjà. Si on le gardait suffisamment longtemps, on aurait le temps de maîtriser un framework, de l’optimiser, de le comprendre. Mais ce n’est pas le cas. Et que l’on ne me dise pas que si on n’avait pas continuellement réinventé la roue, on aurait encore des roues en pierre… Innover serait d’améliorer les frameworks existants .

Sur les langages, c’est la même rengaine. Attention, je ne préconise pas de rester sur l’assembleur et sur le C… C’est le cas par exemple dans le monde Android, pendant plus de 10 ans les développeurs ont pu travailler sur des outils et des frameworks Java. Et comme cela, par magie, le nouveau Langage de la communauté est Kotlin. On imagine l’impact sur les applications existantes (si elles doivent changer), il faut recréer des outils, retrouver des bonnes pratiques… Pour quel gain?

Sincèrement, on ne voit aucun ralentissement sur les cycles de renouvellement des technologies. C’est toujours un rythme frénétique. Nous trouverons bien le Graal un jour. Le problème est ensuite l’empilement de ses technologies. Comme aucune ne meurt vraiment et que l’on en maintient toujours des parties, on développe d’autres couches pour s’adapter et continuer à maintenir ces bouts de code ou ces librairies. Le problèmen’est pas le code legacy,, c’est la glue que l’on développe autour qui pêche.

Au final, on passe du temps à résoudre des problèmes techniques internes, on recherche des outils pour résoudre les problèmes que l’on ajoute, on passe son temps à s’adapter à ses nouveaux outils, on ajoute des surcouches (voir chapitre précédent…) … et on n’a pas améliorer la qualité intrinsèque du logiciel ou les besoins auxquels on doit répondre.

Au final, le rythme frénétique des changements ne nous permet pas de nous stabiliser sur une technologie. J’avoue qu’en tant que vieux développeur que je suis, j’ai été découragé par le changement Java vers Kotlin pour Android. C’est peut-être pour certains de véritables challenges, mais quand je repense au temps que j’ai passé sur l’apprentissage, sur la mise en place d’outils

Ensuite, comme aucune solution ne meurt vraiment, que de nouvelles arrivent… on se retrouve avec des projets avec des multitudes de technologies à gérer avec les compétences associées aussi… On s’étonne ensuite que le marché du recrutement de développeur soit bouché. Pas étonnant.. Il y a énormément de développeurs mais il est difficile de trouver un développeur React avec 5 ans d’expérience qui connaîsse le Go. Le marché est fractionné, comme les technologies. C’est peut-être bon pour les développeurs car cela crée de la rareté et cela fait monter les prix, mais pas pour le projet !

Cependant, cet apprentissage continu des technologies pose le problème d’apprentissage de domaines transverses : accessibilité, agilité, performance… En effet, qu’est-ce qui nous prouve que les outils et les langages que nous allons choisir ne vont pas changer dans 4 ans ? Rust, Go… dans 2 ans ? Rien ne tend à donner une tendance.

On ne se remet pas en question car on veut s’amuser. Le fun est important, car si l’on s’ennuie dans son boulot, on va déprimer. Par contre, on ne peut pas, sous prétexte de vouloir du fun tout le temps, changer nos outils continuellement. Il y a un déséquilibre entre l’expérience du développeur et l’expérience de l’utilisateur. On veut du fun, mais qu’est-ce que cela va réellement apporter à l’utilisateur ? Un produit plus « joyeux » ? Non, nous ne sommes pas des acteurs.

On ne se pose pas de question sur l’éthique de notre domaine, sur sa durabilité… Cela vient peut-être du fait que notre domaine n’a pas réellement de code éthique (comme par exemple les médecins ou les avocats). Mais sommes-nous en tant que développeurs réellement libres si l’on ne peut pas avoir une autocritique ? Nous sommes peut être asservis à une cause portée par d’autres personnes ? Le problème n’est pas simple mais nous avons dans tous les cas une responsabilité. Sans code éthique, c’est le plus fort et le plus malhonnête qui est le plus fort. Le buzz et les pratiques pour manipuler les utilisateurs sont de plus en plus répandus. Sans Dark Pattern ton produit ne sera rien. Les plus gros (GAFA…) n’en sont pas arrivés là pour rien.

Car si cette structuration n’est pas faite, les développeurs vont perdre la main sur ce qu’ils font. Or le manque d’éthique de la profession est critiqué à l’extérieur. Rachel Coldicutt (@rachelcoldicutt) directrice de DotEveryOne, un think tank britannique qui promeut une technologie plus responsable, encourage à former des diplômés non-informaticiens qui traiteraient de ces problèmes (Voir plus précisément dans l’article d’Internet Actu). Pour poursuivre sur ce dernier article, cela serait dans la droite ligne de l’informatique, domaine issu du monde militaire où les ingénieurs et développeurs seraient formés à suivre des décisions et des commandements.

Si ces décisions absurdes arrivent, ce n’est pas uniquement la faute du développeur mais bien de l’organisation. Et qui dit organisation dit management (sous-différente forme). Si l’on revient au livre de Morel, il parle de piège cognitif dans lesquels les managers et les techniciens tombent souvent. C’est le cas de la navette Challenger qui a été quand même lancée malgré la connaissance du problème d’un joint défectueux. Les managers ont sous-évalué les risques et les ingénieurs ne les ont pas prouvés. Chacun a reproché à l’autre de ne pas fournir assez de preuves scientifiques. C’est souvent ce qui se passe dans les entreprises : des warnings sont levés par certains développeurs mais le management ne les prend pas assez au sérieux.

En même temps, on revient aux causes précédentes (silver bullet, on s’amuse…), il est nécessaire d’avoir une vraie ingénierie et une vraie analyse des technologies. Sans cela, les équipes techniques seront toujours non-écoutées par le management. Des outils et benchmark existent mais ils sont encore trop peu connus. Par exemple, Technologie Radar qui classe les technologies en terme d’adoption.

Ce phénomène de décision absurde est renforcé par le tissu complexe du développement logiciel : Les sociétés historiquement hors du numérique sous-traitent à des entreprises du numérique, les ESN sous-traitent aux freelances… Le partage de responsabilité technique / management est encore plus complexe et les décisions absurdes plus nombreuses.

Mais cela ne s’arrête pas là. On peut aussi voir l’usage de l’open-source comme une sorte de sous-traitance. Idem pour l’usage de framework. On est juste consommateur passif, on se déleste de plein de problématiques (qui ont un impact sur les ressources, la qualité…).

C’est d’autant plus facile que le domaine est passionnant et que la pratique des sides-projects, du temps passé sur les projets open-source hors des horaires de bureau est chose commune… La recherche de “fun” et le temps passé bénéficient alors plus aux organisations qu’aux développeurs. Difficile dans ce cas de chiffrer le coût réel d’un projet. Et pourtant, cela ne serait pas un problème si on arrivait à des logiciels « au top ».

Le développeur n’est ici plus un artisan du code, mais plutôt un pion dans un système critiquable du point de vue humain. Cela n’est pas visible, tout va bien et on s’amuse. En apparence seulement, car certains domaines du développement logiciel vont plus loin et rendent beaucoup plus visible cette exploitation : Le domaine du jeux-vidéo où les heures explosent.

Et donc, toutes ces maladresses (logiciel trop lourd, sans qualité…) se retrouvent chez les utilisateurs. Comme on doit releaser au plus vite les logiciels, que l’on ne tente pas de résoudre les inefficiences internes, et que l’on ne met pas plus de ressource pour faire de la qualité, on arrive à des logiciels médiocres. Mais on a tellement d’outils de monitoring et de suivi des utilisateurs pour détecter ce qui se passe directement chez eux qu’au final, on pense que ce n’est pas grave. Cela serait une bonne idée si les outils étaient bien utilisés. Or la multitude d’informations récoltées (en plus des bugs remontés par les utilisateurs) n’est que faiblement utilisée. Trop d’information, difficulté de cibler la vraie source du problème… on s’y perd et au final, c’est l’utilisateur qui trinque. Tous les logiciels sont maintenant en bêta-test. A quoi bon faire de la sur-qualité, autant attendre que l’utilisateur le demande. Et on revient ainsi au premier chapitre : un logiciel uniformément lent … et médiocre.

L’informatique du 21ème siècle est ce que l’agroalimentaire était pour les consommateurs au 20ème siècle. Pour des raisons de productivité, on a poussé des solutions médiocres avec un calcul court-termiste : mise sur le marché de plus en plus rapide, profit en hausse constante… agriculture intensive, malbouffe, pesticides… avec des impacts importants sur la santé, sur l’environnement… Les consommateurs savent maintenant (de plus en plus) les conséquences désastreuses de ces dérives, l’industrie agroalimentaire doit donc se réinventer, techniquement, commercialement et éthiquement. Pour le logiciel, quand les utilisateurs comprendront les tenants et les aboutissants des choix techniques, l’industrie du logiciel devra gérer les mêmes problèmes. En effet, le retour au bon sens et aux bonnes pratiques n’est pas une chose simple pour l’agroalimentaire. Dans l’IT, on commence à le voir avec ses conséquence sur la vie privée des utilisateurs (mais nous n’en sommes qu’aux balbutiements).

On va dans la mauvaise direction. L’industrie de l’informatique a déjà effectué dans les années 70 des erreurs avec des impacts non-négligeables. L’exclusion des femmes de l’informatique en fait partie. Non seulement cela a été fatal pour certaines industries mais on peut se poser la question de comment on peut maintenant adresser des réponses à seulement 50% de la population informatique, avec une représentativité très faible. Le chemin est maintenant difficile à retrouver.

Mais l’impact du monde IT ne s’arrête pas là. La source et le modèle d’une grosse partie de l’informatique sont issus de la Silicon valley. Si l’on écarte les gagnants de la Silicon Valley, les populations locales subissent la montée des prix, le déclassement, la pauvreté…

Dans sa lancée vers le progrès technique, le monde du logiciel crée aussi sa dette environnementale…