des pisteurs pour les réduire au strict nécessaire. En effet, les pisteurs génèrent des requêtes HTTP supplémentaires à chaque consultation de page, l’ordre de grandeur pouvant être de 20 à 100 requêtes HTTP supplémentaires par page consultée selon Benjamin Bayart.
Bien sûr, la réduction de requêtes HTTP n’est pas notre seule motivation : nous évoquions les problèmes que ces pisteurs posent sur le plan du non-respect de la vie privée dans cet article. En poussant plus loin les réflexions sur le numérique responsable, nous cheminons doucement vers une définition sur le “comment concevoir des services numériques responsables” : en faisant en sorte qu'ils soient écoconçus, accessibles, inclusifs et respectueux de la vie privée by design.
Il s’ouvre à nous également la question de la finalité du service numérique, finalité qui est décidée par nos clients, mais sur laquelle nous souhaitons de plus en plus les questionner, les influencer et les orienter vers du numérique utile socialement et écologiquement, mais ce serait une autre histoire à raconter. Dans cet article, nous nous concentrerons sur ce pistage de pisteurs en tant que prise de responsabilité des artisans de logiciel.
En premier lieu, nous nous attaquons aux pisteurs publicitaires pouvant être malencontreusement insérés dans nos développements pour nos clients, par le biais d’autres bibliothèques embarquées dans un projet.
Pour cela, l’outil exodus-standalone, proposé par l’association Exodus Privacy, est parfaitement adapté pour les applications Android. Comme mentionné ci-dessus, nous avons déjà publié un article sur le sujet pour vous aider à l’intégrer dans votre CI/CD et ainsi bloquer le processus de déploiement en cas de détection de pisteur. Nous invitons également les personnes peu familières avec le concept de pisteurs, traqueurs, traceurs à lire ce même article.
Cependant, lors d’une expérimentation sur la mesure d’impact que nous avons commencé à raconter ici, nous voulions pister les pisteurs sur une application iOS. Or exodus-standalone est restreint aux applications Android. Comme l’application en question était développée sous Flutter (même base de code pour l’application Android et iOS), en première approximation nous avons pris l’hypothèse que la détection de pisteurs sur l’app Android nous donnerait une idée des pisteurs sur l’app iOS. L’équipe de dev nous avait indiqué que l’app contenait quelques pisteurs d’activité, et aucun pisteur publicitaire. L’absence de pisteur publicitaire a pu être confirmée sur l’application Android.
Pour autant, nous nous sommes posé la question de l’absence d’outil sur iOS. Les DRM d’Apple empêchent la mise à disposition par une association d’un tel outil grand public. Or, en tant que concepteur d’applications pour le compte de nos clients, nous voulons contrôler les applications que nous développons, dans nos CI/CD, pour garantir l’absence de pisteurs publicitaires à nos clients. Nous, et tout particulièrement Simon, Svetlana, Alaeddine, avons voulu tester la faisabilité technique d’un tel outil sur iOS, c’est chose faite : ça fonctionne. Nous avons déposé le code en open-source sur GitHub. Il manque cependant quelques éléments pour que l’outil fonctionne comme sur Android, et en particulier la création et l’enrichissement de la base de connaissances contenant la liste des pisteurs connus sous iOS. À ce stade, au regard de nos pratiques de développement mobile, plutôt orientés sur Flutter et majoritairement sur Android, nous ne souhaitons pas continuer le développement de cet outil et le mettons à la disposition de la communauté des développeurs iOS si cela peut être utile.
À OCTO nous allons utiliser exodus-standalone dans nos pipelines de développement comme le décrit Simon dans son article Détectez les pisteurs et dans le Readme de l’outil pour GitLab CI/CD et GitHub Actions. Nous prendrons l’hypothèse que si les pisteurs sont absents de la version Android d’une application mobile développée sur Flutter alors ils seront également absents de la version iOS.
De plus, l’outil exodus-standalone permet maintenant d’ignorer la présence d’un pisteur si cela est souhaité par la personne qui développe, partant du principe que le numérique responsable repose d’abord sur la responsabilité des concepteurs et développeurs d’applications.
On mesure le chemin que nous avons parcouru vers un numérique plus responsable aux changements concrets de nos pratiques. L’utilisation de plus en plus systématique d’exodus-standalone en est un exemple. La réduction du nombre de pisteurs d’activité au strict nécessaire serait un bon prochain pas. La sensibilisation aux enjeux du numérique responsable pendant le séminaire d’intégration des nouveaux Octos et nos formations autour de l’écoconception sont une autre façon d’accélérer. Et il est certain que tout ceci n’est que le début du chemin vers un numérique plus sobre, plus accessible, plus inclusif, plus respectueux de la vie privée, en bref vers un numérique souhaitable. Et pour vous, ce serait quoi un numérique souhaitable ?