CONCLUSIONS DE L’ÉTUDE
Développement d’outils dans le domaine de la documentation sur les droits de l’homme
Vous trouverez ci-dessous les principales conclusions de l’étude menée par The Engine Room sur le développement d’outils dans le domaine de la documentation sur les droits de l’homme.
Pour cette étude, The Engine Room a conduit huit entretiens avec des développeurs d’outils, et a effectué une recherche indépendante sur les outils pertinents. Les conclusions détaillées ont été rédigées pour ce site par The Engine Room.
Conclusions
Les documentalistes de la société civile sur les violations des droits de l’homme opèrent généralement dans des contextes à haut risque avec des ressources limitées. Ceci, associé aux rapides changements technologiques, engendre certains obstacles pour les développeurs.
Dans notre étude, nous avons identifié deux domaines notables dans lesquels les développeurs sont confrontés à ces difficultés : maintenir un outil sur le long terme et trouver le bon équilibre entre les fonctionnalités.
Nous avons également constaté une tendance actuelle chez les développeurs de ce domaine à créer des outils plus modestes et plus ciblés, pensés comme partie intégrante d’un plus grand écosystème d’outils. Certains développeurs coopèrent également pour rendre leurs outils interopérables.
Vous trouverez ci-dessous quelques-unes de nos principales conclusions.
01.
Les ressources nécessaires au maintien d’un outil sur le long terme sont difficiles à financer, et sous-estimées
Les ressources souvent très limitées des documentalistes conditionnent la manière dont les développeurs peuvent financer leurs outils.
La plupart des développeurs auxquels nous avons parlé déclarent être confrontés à des difficultés de financement, en particulier pour la durabilité de leurs outils et l’assistance technique à long terme. Certains déclarent également qu’ils ont sous-estimé le nombre de ressources nécessaires pour maintenir leurs outils sur le long terme.
Qu’implique le maintien d’un outil?
Maintenir un outil avec efficacité sur le long terme signifie s’assurer que l’outil continue à fonctionner correctement et qu’il suit l’évolution des besoins des utilisateurs. En ce qui concerne les implications, l’étude a révélé les éléments suivants :
- Réagir rapidement aux bugs et autres problèmes.
- Répondre aux changements en cas de dépendances à des outils et des langages de programmation, en particulier pour les dépendances à des composants et les dépendances de sécurité.
- Effectuer un support général du back-end (maintenance des serveurs et sécurité des applications).
- Effectuer des audits réguliers ou des tests d’intrusion pour trouver les failles de sécurité.
- Fournir une assistance aux utilisateurs, notamment en répondant aux demandes et en développant les fonctionnalités demandées.
- Réaliser des tests utilisateurs, des formations, des ateliers et des actions de sensibilisation.
- S’adapter à l’évolution des règles et des attentes des utilisateurs en ce qui concerne l’aspect, la convivialité et le fonctionnement des outils
Comment les ressources impactent les stratégies d’audits de sécurité et de tests d’intrusion
Bien qu’importants, les audits de sécurité et les tests robustes d’intrusion s’avèrent difficiles à financer par les développeurs, et les logiciels proposés peuvent donner des résultats insatisfaisants.
- Les développeurs disposant de ressources plus solides déclarent qu’ils sont en mesure d’effectuer des audits ou des tests plusieurs fois par an, en essayant d’alterner les sociétés de test, et de re-tester leur solution une fois les corrections apportées.
- Un développeur interrogé a déclaré qu’en raison de ses ressources limitées, la plupart des audits de son outil avaient été réalisés non pas par lui-même, mais par des organisations qui voulaient l’utiliser pour leur travail de documentation. Elles avaient comparé l’outil à un logiciel standardisé qui produisait des résultats superficiels et parfois « désordonnés ».
Les développeurs qui travaillent depuis longtemps dans ce domaine doivent surmonter des difficultés particulières pour combler le fossé entre le contexte dans lequel l’outil a été créé et l’environnement actuel, tant sur le plan des attentes des utilisateurs que sur le plan technologique (par exemple, pour les langages informatiques utilisés).
Concernant l’évolution des attentes des utilisateurs au cours des dernières années, les développeurs précisent que les utilisateurs sont désormais habitués à des fonctionnalités plus intuitives, à des interfaces Web, à un accès multi-appareil facile et à un support client. Les développeurs d’outils de gestion de données déclarent également qu’on leur demandait plus de fonctionnalités de visualisation et d’analyse.
Quand mettre un outil au rebut ?
Au cours des dernières années, un certain nombre d’outils bien établis dans le domaine de la documentation des droits de l’homme ont été abandonnés.
Les discussions avec des développeurs qui ont pris la difficile décision d’arrêter un outil (arrêter de le maintenir ou d’en assurer l’assistance technique) indiquent que la décision est souvent prise lorsque l’outil commence à devenir trop lourd en termes de ressources. Le développeur ne peut donc plus maintenir l’outil correctement, et lorsqu’il devient simultanément moins pertinent au regard des attentes actuelles des utilisateurs, retirer l’outil semble alors la solution la plus logique.
Dans certains cas, les ressources sont transférées dans un nouvel outil, ou redirigées vers l’un des autres outils du développeur.
1.1 Comment les développeurs financent la pérennisation de leurs outils
En discutant avec les développeurs, nous avons constaté une grande diversité de modèles et stratégies de financement pour assurer la pérennité des outils. Certains s’appuient entièrement sur des subventions, certains ne comptent que sur des services payants, et les autres combinent les deux.
Financement par subvention
- De nombreux développeurs dépendent au moins en partie de subventions, mais la plupart d’entre eux déclarent éprouver des difficultés à financer leur travail au-delà de la phase initiale de création de l’outil.
- Des serveurs spécifiquement financés permettent aux développeurs de proposer gratuitement des versions hébergées de leur outil : KoBoToolbox, par exemple, offre un hébergement gratuit et illimité aux organisations humanitaires sur un serveur spécifique fourni par l’ONU.
Services payants
- Les services qui génèrent des revenus couvrent des éléments tels que l’installation et l’hébergement, la personnalisation des outils pour répondre à des besoins et des processus spécifiques, et la fourniture de formations et d’une assistance régulière.
- Le fait de fournir des services aux organisations disposant de ressources plus importantes permet à un développeur d’offrir des services à un prix symbolique aux organisations disposant de peu de ressources.
- Difficultés : Certains indiquent que répondre aux demandes spécifiques implique moins de ressources pour travailler sur les fonctionnalités dont ils connaissent le besoin. Néanmoins, ils ont pu réinjecter dans l’outil principal les fonctionnalités utiles développées pour les versions personnalisées.
Financement par abonnements
- Ce modèle a été proposé par un développeur comme un scénario futur, dans lequel les abonnements des membres seraient utilisés pour financer les frais de maintenance, et tout ce qui resterait serait utilisé pour de nouvelles fonctionnalités, décidées par les membres eux-mêmes.
1.2 La création d’outils open-source comme stratégie de durabilité
Un développeur a mentionné l’utilisation et la construction d’une technologie open source comme stratégie de durabilité pour son outil. Il déclare:
“Construire un outil à l’aide d’un logiciel fiable, bien entretenu et largement utilisé, est important pour que d’autres développeurs puissent apporter des modifications et des améliorations si [our own] propres financements venaient à manquer. Ne compter que sur un ou deux développeurs qui connaissent le code présente le risque de rendre très difficile la création d’une communauté de développeurs autour de l’outil.”
02.
Les développeurs construisent des outils plus petits qui s’inscrivent dans un écosystème plus vaste
Nos recherches ont montré que les acteurs du domaine s’éloignent souvent de plus en plus des grosses applications fourre-tout (Martus, aujourd’hui obsolète, en est un exemple. Ils s’orientent vers un écosystème de petites applications visant à répondre à un ensemble plus limité de besoins, mais pouvant être utilisées ensemble dans un même processus. Parmi les raisons évoquées, citons :
- Un lourd outil lourd et « fourre-tout » peut assurer un haut niveau de sécurité ou une palette de fonctionnalités différentes, mais il peut aussi se révéler plus difficile à utiliser pour les organisations qui n’ont pas forcément besoin de toutes ces fonctionnalités. Il peut aussi représenter une lourde charge pour les développeurs.
- Construire un outil intégré dans un écosystème plus large peut s’avérer plus pratique à maintenir pour les organisations individuelles. Certains développeurs estiment que cette approche pourrait aussi offrir une certaine flexibilité dans le futur:
« Combiner les outils favorise une approche plus tactique, plus agile, qui répond plus précisément aux besoins de contextes en évolution. On rencontre moins souvent un point d’échec unique.”
Dans certains cas, les développeurs coopèrent activement pour rendre leurs outils interopérables. Pour connaître quelques exemples, consultez le Tableau des outils.
03.
Pour trouver le bon équilibre de fonctionnalités, les développeurs d’outils sont souvent confrontés à des compromis
Bon nombre des développeurs avec lesquels nous nous sommes entretenus ont déclaré que l’outil final avait été élaboré par étapes, en tirant les leçons des difficultés passées, en expérimentant les fonctionnalités et en écoutant attentivement les retours des utilisateurs.
Dans tous les cas, de nombreuses décisions clés relatives aux fonctionnalités ont dû être prises en cours de route, et celles-ci impliquaient souvent de faire des compromis. Notre étude a mis en évidence deux compromis majeurs :
- sécurité vs convivialité, et
- flexibilité vs processus structurés
3.1 Sécurité vs convivialité
La gestion de la sécurité dans le contexte de notre étude est complexe et peut être assurée de différentes manières, en répondant à différents scénarios et en abordant différents types et niveaux de risque. Les développeurs interrogés soulignent que, quelle que soit la manière dont la question de la sécurité est abordée, trouver le bon équilibre entre sécurité et convivialité pour les utilisateurs est essentiel.
Une approche commune aux développeurs confrontés à ces enjeux de sécurité et de convivialité consiste à travailler de préférence directement avec des groupes et des organisations spécifiques qui souhaitent utiliser l’outil ou qui répondent au scénario d’utilisation idéale, plutôt que de viser une adoption individuelle généralisée. Cette approche mène à une meilleure adoption plus réussie de ces outils, bien que le nombre d’utilisateurs paraisse potentiellement plus faible.
Le compromis sécurité/convivialité est un problème particulièrement épineux pour les outils de gestion, d’analyse et de visualisation des données.
Les développeurs de ces types d’outils relèvent que :
- Certaines fonctions de haute sécurité, telles que le chiffrement de bout en bout, peuvent rendre l’accès, la gestion et l’analyse des données très difficiles, et peuvent entraîner une perte de données irrémédiable en cas de perte des clés de chiffrement.
- Les outils qui répondent à des modèles de risques très complexes, mais qui sont difficiles à utiliser pour les utilisateurs ciblés peuvent avoir du mal à être adoptés. Cette approche peut également aboutir à une compromission de la sécurité de manière non intentionnelle :
“Nous avons constaté que lorsque les [security features] compliquent trop le travail sur les données, les gens les contournent. Vous disposez donc d’un outil magnifique [extrêmement sécurisé] en théorie, mais les gens le déjouent.” Un développeur d’outils
En raison de cette situation et de l’expérience acquise sur le terrain ces dernières années, les outils dont la principale fonctionnalité est l’organisation, l’analyse ou la visualisation privilégient la facilité d’utilisation plutôt que la capacité à réagir à des menaces très complexes.
3.2 Flexibilité vs structure du processus
En général, les développeurs observent qu’un certain niveau de flexibilité au sein des applications peut mener à une situation gagnant-gagnant: les utilisateurs de l’outil sont heureux de pouvoir adapter l’outil eux-mêmes, et les développeurs apprécient l’allègement la réduction de la charge de support.
Toutefois, comme l’a fait remarquer un développeur d’outils : avec trop de flexibilité, l’utilisateur n’a pas de chemin prédéfini ou de ligne directrice à travers l’application.
Flexibilité, mais avec des « valeurs par défaut pertinentes ».
Un développeur propose d’apporter une certaine flexibilité, tout en proposant des valeurs prédéfinies pertinentes :
“Cet outil cible n’est pas une nouveauté, mais un « avenir idéal ». Les organisations qui travaillent avec un processus de travail défini apprécient parce qu’il vous fait avancer et élimine une partie de la complexité.”
Ces valeurs prérenseignées pourraient inclure les éléments suivants :
- Des modèles et des formulaires types (par exemple, un formulaire couvrant les informations requises au minimum pour un certain type de soumission, à un système judiciaire particulier).
- Des catégories par défaut (les pays, les types de violation, etc.) et des structures de données (la mise en relation de différents types de données entre elles par exemple).
- L’interopérabilité par défaut avec une autre application pour une partie différente du processus de collecte et de gestion des données.
- Des options pour la visualisation des données.
Dans le cadre d’un outil qui conserve une certaine flexibilité, ces valeurs par défaut pourraient ensuite idéalement être modifiées, supprimées ou ajoutées par l’organisation qui configure l’outil.