Luc Véronneau et la création de logiciels qui font sens
Entretien avec l’architecte de solutions Luc Véronneau
Écrit par l’équipe de coordination du PDS*
An English version of this post was published here.
L’équipe du Pôle d’analyse de données sociales (PDS) s’est entretenue avec Luc Véronneau pour en apprendre davantage sur son rôle en tant qu’architecte de solutions, son implication dans le projet ainsi que les objectifs de son équipe pour l’année à venir.
Quel est votre rôle au sein du PDS?
Luc Véronneau (LV): J’étais en contact avec le CRIEM [Centre de recherches interdisciplinaires en études montréalaises] bien avant que le PDS voie le jour. Mon rôle s’apparentait à celui d’un «spécialiste technique». J’effectuais un travail d’architecte de solutions en discutant de l’Observatoire des récits de Montréal (lequel a depuis été scindé en deux projets) et en élaborant la solution pour Commun Axiom, qui est une idée que j’ai eue.
Actuellement, mon titre officiel est «architecte de solutions», mais mes fonctions s’étendent au-delà de ce poste. Je suis responsable de l’équipe de développement, ce qui signifie que j’encadre les développeur·se·s et que je révise leur code. Je m’occupe aussi de la conception de logiciel, en plus de guider l’équipe dans la mise en œuvre de ces structures.
Mes tâches incluent la sélection de piles technologiques et la formulation de directives quant à leur déploiement, car les développeur·se·s que nous avons en ce moment sont des étudiant·e·s. Il·elle·s n’ont pas autant d’expérience que moi, donc je dois généralement passer en revue leur code et leur donner des conseils. Une grande partie de mon travail consiste à les encadrer. Cela dit, il·elle·s sont plus spécialisé·e·s que moi; nous bénéficions donc beaucoup de cette collaboration sur d’autres aspects.
Mon rôle consiste aussi à rencontrer d’autres leaders techniques au sein de Montréal en commun afin d’être au fait de leurs travaux [ainsi que] des lignes directrices ou des restrictions en matière d’architecture logicielle. De plus, je reste en contact avec les partenaires et différent·e·s membres de l’équipe afin de me tenir au courant des projets susceptibles de s’arrimer avec nos propres initiatives technologiques. Cela implique des partenariats approfondis avec des gens qui ne sont pas directement liés au PDS, mais qui pourraient être intéressés par l’utilisation de certaines de nos solutions à long terme. Nous ne développons pas un logiciel pouvant seulement répondre aux besoins d’un regroupement précis d’organismes; le but, c’est d’offrir quelque chose qui sera accessible à un plus large public.
Nous ne développons pas un logiciel pouvant seulement répondre aux besoins d’un regroupement précis d’organismes; le but, c’est d’offrir quelque chose qui sera accessible à un plus large public.
Qu’est-ce qu’un «architecte de solutions» exactement?
LV: Je vais vous donner ma propre définition de ce terme, puisqu’il en existe plusieurs. Habituellement, une personne qui agit comme «architecte de solutions» sélectionne quel logiciel sera utilisé et comment celui-ci sera assemblé pour répondre aux besoins de base d’une entreprise. Cela dépasse la conception d’un seul logiciel — l’architecte doit déterminer quels logiciels différents fonctionneront de pair pour assurer le roulement de l’entreprise.
Cela dit, il y a aussi ce que nous appelons des «architectes d’entreprise», qui gèrent les choses d’un point de vue plus large. Il·elle·s ne s’occupent pas seulement des logiciels, mais tiennent aussi compte des besoins particuliers d’une entreprise et décident si des personnes ou des technologies seront sollicitées pour les satisfaire.
Les architectes de solutions doivent aussi penser à ces enjeux, car toute «mise en œuvre d’une solution» implique qu’il y a un problème à résoudre ou un besoin à combler. Les besoins d’une entreprise pourraient être mieux servis par le déploiement d’une solution logicielle, par le renforcement du personnel ou encore par [la redistribution] des responsabilités parmi le personnel actuel.
Il faut réfléchir à ce qu’est une «fonction». Pas en matière de logiciel — les gens dans ce domaine pourraient concevoir cette idée comme une portion de code, mais une fonction représente bien plus que cela. Les personnes qui travaillent au sein de toute organisation ont des fonctions qui sont généralement désignées par leur titre. Ces fonctions ne peuvent pas toujours être automatisées donc il faut cerner quelles parties que l’on peut automatiser au moyen d’un logiciel, et inversement.
Il faut aussi s’assurer que les gens tirent le meilleur parti de leurs efforts en instaurant le bon logiciel aux niveaux appropriés, car un mauvais logiciel peut compliquer le travail des gens. Il s’agit généralement d’une mauvaise solution; les gens s’exaspèrent vraiment lorsqu’ils ont affaire à ce type de logiciel.
Ainsi, ce qu’on cherche à faire comme architecte de solutions consiste à répondre aux besoins de tout le monde. Cela implique de parler aux futur·e·s utilisateur·rice·s du logiciel afin d’avoir une meilleure idée de leurs rôles au sein de l’entreprise. On demande à la fois à [la haute administration] et aux gens sur le terrain ce qu’ils font et comment la mise en œuvre logicielle pourrait aider leur travail.
C’est en couvrant ces bases que l’on peut établir une structure des différentes fonctions exécutées au sein de l’entreprise, et voir lesquelles peuvent ou non s’automatiser à l’aide d’un logiciel. On peut voir comment faciliter le travail des personnes afin qu’elles puissent assumer des tâches plus intéressantes et réduire les efforts requis pour les aspects répétitifs [de leur emploi] — ceux que l’on peut déléguer à un logiciel.
Quel est l’objectif de Commun Axiom?
LV: D’un point de vue social, l’objectif de Commun Axiom est de produire quelque chose d’utile pour les petites organisations. Dans le cadre de mon travail dans le secteur privé, j’ai vu qu’il existe plusieurs solutions pour les grandes entreprises et les individus. Toutefois, les petites entreprises n’ont souvent pas les moyens d’investir dans des solutions d’envergure ni l’infrastructure pour gérer des logiciels complexes; pourtant, elles ont quand même besoin d’une certaine forme d’informatique décisionnelle pour le traitement de leurs données. Commun Axiom se destine vraiment à pallier cet écart technologique qui me semblait évident.
J’ai toujours su qu’il n’y aurait pas d’argent à tirer de la solution. C’est un logiciel gratuit. Le produit vise à être décentralisé et hébergé sur une base volontaire, donc il n’y a aucune [intention de monétisation] du logiciel lui-même. À long terme, je vais peut-être obtenir un financement quelconque pour le maintenir en vie, mais cela ne signifie pas que sa valeur augmentera. Pour moi, le meilleur profit que je peux tirer, c’est que Commun Axiom soit utilisé. Parce que les gens peuvent réellement trouver des façons d’améliorer leur vie à l’aide du logiciel.
Qu’est-ce qui vous motive et vous inspire à participer au PDS?
LV: Évidemment, d’un point de vue technologique, ce projet est super intéressant. Outre le fait que nous aidons vraiment les organismes, l’aspect technique de la solution est intéressant en soi parce qu’il n’existe rien de comparable. Nous reprenons les principes de logiciels existants, mais sous des formes inédites et en utilisant une approche décentralisée.
J’ai regardé les solutions disponibles pour les universités quant à l’entrée d’informations dans un répertoire mis à la disposition d’autrui. C’est très centralisé, souvent incommode, et les seules options décentralisées qui existent en ce moment sont très peu sécuritaires. Dropbox n’est pas très confidentiel: il est facile de [perdre notre confidentialité] en perdant notre URL quelque part, en le copiant-collant sur la mauvaise page ou en le partageant avec la mauvaise personne. De plus, il n’y a pas de moyen facile de savoir où va l’information et comment elle est utilisée.
Ainsi, en matière de gouvernance des données, Dropbox, Google Drive, Microsoft OneDrive et autres produits similaires ne remplissent pas réellement les exigences de protection de la confidentialité, d’anonymisation ou même de protection de la propriété intellectuelle et du suivi de l’utilisation de nos données à long terme. Plusieurs options s’avèrent aussi trop techniques pour être employées par la majorité des gens. Ce sont ces éléments que nous cherchons à offrir aux futur·e·s utilisateur·rice·s de Commun Axiom. Nous couvrons de nombreuses considérations différentes qui ne sont généralement pas l’apanage d’une seule solution.
Outre le fait que nous aidons vraiment les organismes, l’aspect technique de la solution est intéressant en soi parce qu’il n’existe rien de comparable.
Qu’avez-vous appris jusqu’à présent à travers votre implication dans le PDS?
LV: À quel point c’est difficile de faire bouger les choses au sein d’organisations. Nous avons un partenariat et tout le monde tend vers un but commun, mais il s’avère très difficile de faire en sorte que ces organisations s’impliquent sérieusement dans le projet et nous indiquent qu’ils ont «besoin de cet élément-ci et de cette fonction-là, puis de telles possibilités pour faciliter le travail».
Ce qui me surprend, c’est que les gens semblent avoir peur de donner des réponses directes [de l’ordre de] «si X était mis en œuvre, je ne l’utiliserais pas». Je suppose que c’est parce qu’ils craignent de s’engager dans quelque chose qui dépasse leur engagement initial. Les gens ne disent pas souvent «c’est une très mauvaise idée», car ils ne veulent probablement pas blesser qui que ce soit, mais, moi, je veux savoir si je me trompe ou si je m’égare! Le fait de ne pas savoir peut définitivement compliquer les choses en matière de processus organisationnels lorsqu’on cherche à susciter un mouvement, à sortir de l’inertie, et à ce qu’il y ait de l’activité.
Le développement logiciel n’est pas aussi difficile même si cela demande beaucoup de travail. Tout dépend vraiment des aspects opérationnels du projet dans son ensemble. Je savais que ce ne serait pas facile, mais je ne pensais pas que ce serait si dur d’obtenir un quelconque mouvement général. Les stratégies permettant d’amener les gens à s’impliquer et à donner leur rétroaction sans sentir qu’ils s’engagent au-delà de leurs attentes — ce sont des choses que l’on apprend seulement par la pratique.
À quels défis le PDS sera-t-il confronté d’ici la fin du projet en décembre 2024?
LV: Le plus grand défi sera de créer une organisation qui pourra survivre au-delà de la phase d’expérimentation initiale. D’ici 2024, nous élaborerons des processus, des logiciels et des principes qui permettront à différents organismes de collaborer et d’en savoir plus sur le contexte dans lequel ils évoluent à Montréal, tout en créant de nouvelles connaissances à travers l’agrégation d’information. Mais ça doit être plus qu’une simple expérience: ça doit être quelque chose qui survit tout seul.
Le CRIEM représente actuellement cette organisation/le PDS, mais au bout du compte il faudra que le projet existe de façon indépendante. Ça nous donne deux ans pour bâtir les fondations de l’organisation et de créer les processus nécessaires à son existence. C’est beaucoup de travail [dans ce laps de temps], car nous devons cerner les rôles clés dans une organisation. Même si nous optons pour une fiducie de données au sein du partenariat — ce qui semble être l’une des solutions intéressantes—, la fiducie de données à elle seule ne peut couvrir toutes les exigences assurant la survie de ces solutions, car nous devons toujours prévoir l’hébergement.
Même avec Commun Axiom, qui est en grande partie décentralisé, certaines composantes devront être hébergées parce que nous identifions les gens lors de la création de comptes et que cela implique un répertoire principal d’individus existants sur le réseau. Le fait d’avoir un orchestrateur centralisé qui transmet et récupère l’information de tout le monde facilite le maintien d’un réseau solide. Mais ces composantes centralisées doivent être hébergées et gérées; nous avons donc besoin d’une organisation qui reçoit du financement pour effectuer ces tâches et faire fonctionner le tout.
Nous pourrions même nous rendre à un point où nous devrons construire deux organisations différentes. L’une serait consacrée au réseau, comme un organisme à but non lucratif qui hébergerait les serveurs principaux en plus de surveiller et de soutenir le développement futur de Commun Axiom. L’autre se spécialiserait dans la production de connaissances sur Montréal et gérerait la gouvernance des données. Les deux organisations seraient complémentaires, mais ne relèveraient pas nécessairement des mêmes personnes ni ne répondraient aux mêmes besoins. Elles ne recevraient donc pas les mêmes budgets.
Ce sera probablement un gros défi, et je pense que tout le monde en a conscience. Il faudra s’y atteler assez rapidement parce que deux ans, ça passe très vite.
Quels objectifs votre équipe s’est-elle fixés pour l’année à venir?
LV: Nous espérons commencer à rencontrer certains partenaires pour définir le type de données et de tableaux de bord que nous leur construirons, en matière d’analyse de données. Nous allons prendre certains jeux de données et passer par tout le processus d’ingestion pour les intégrer à ces tableaux de bord.
J’espère aussi que de nouveaux·elles coéquipier·ère·s commenceront à travailler avec nous. Ana [Brandusescu] et Jonathan [Van Geuns] vont travailler sur tout l’aspect de la gouvernance des données au sein du projet. Le duo agira à titre d’autorité en matière de gouvernance des données et imposera des contraintes ou des restrictions sur les jeux de données étudiés et ingérés, afin que nous puissions y ajouter des métainformations pour définir les transformations de nettoyage préalables à leur utilisation. Nous aurons ainsi l’occasion de démontrer tout le processus de gouvernance des données qui sera à terme effectué par le biais de la plateforme de Commun Axiom, surtout dans le contexte d’une fiducie de données. Ce sera donc une sorte de test en vue de quelque chose de plus grand.
Avec Commun Axiom, nous envisageons de tester les bases du transfert de données à partir de l’application Partages au cours de la prochaine année. Une fois que ce sera fait, nous aurons l’infrastructure de base pour commencer l’automatisation du transfert de données, puis nous pourrons élaborer toute l’infrastructure de métadonnées pour que les gens puissent commencer à documenter les jeux de données dont ils disposent, s’ils sont accessibles ou non et pourquoi.
Nous espérons aussi commencer à travailler sur une autre application appelée Ententes, qui définira les conditions du partage de données entre différentes parties. Lorsque ces éléments commenceront à émerger, ils fourniront les outils appropriés pour l’exercice d’une fiducie de données dans le contexte de Commun Axiom.
Il y a donc plusieurs objectifs à atteindre pour l’année à venir, mais je pense que nous sommes sur la bonne voie.
Cet entretien a été modifié par souci de concision et de clarté.
Rédaction: Angelina Mazza; révision du contenu: Karolyne Arseneault, Julie Levasseur et Luc Véronneau; traduction: Julie Levasseur; révision de la traduction: Karolina Roman.
Le Pôle d’analyse de données sociales est un projet de Montréal en commun, une communauté de projets d’innovation dans le cadre du Défi des villes intelligentes.
