Le travail d’Échirolles sur les logiciels libres concerne l’ensemble des applications numériques de la ville. La réflexion sur la mise en œuvre d’une nouvelle solution commence toujours par le même questionnement :

1. Un logiciel déjà présent dans la collectivité nous permet-il de répondre au besoin exprimé ?
2. Si non, existe-t-il un logiciel libre (ou open source) permettant de l’adresser ?
3. Si non, existe-t-il un logiciel propriétaire pour ce faire ?
4. Si non, développons le logiciel ou la fonctionnalité qui manque.

Si le passage au libre de suites bureautiques, de systèmes d’exploitation ou de logiciels métiers est bien documenté, notre méthode est parfois appliquée à des domaines un plus surprenants. C’est ainsi que nous nous sommes penchés sur notre interphonie.

L’interphone est un élément de sécurité qu’on trouve dans toutes sortes de structures (collectivités de toutes tailles, entreprises, copropriétés…) et de nombreux constructeurs sont positionnés sur le marché. De nos jours, tous les interphones et visiophones sont « connectés ». Le hic : des solutions logicielles propriétaires, opaques et sur lesquelles il n’est pas possible d’avoir la main. Vous êtes dépendant de votre fournisseur, autant dans votre capacité à réagir en cas de problème que pour ce qui concerne la sécurité de votre installation.

Forte de ses 21 écoles, de plusieurs crèches et autres accueils à destination de la petite enfance, Échirolles se pose la question du déploiement de visiophones dans une infrastructure sécurisée, souveraine, cohérente et correctement gérée.

Des interphones existent déjà, évidemment, mais ils ont été installées au fil de l’eau, reposent parfois sur des solutions analogiques, des matériels variés, et sont associés à des contrats de maintenance divers… bref : il est peut-être temps de moderniser et de rationaliser la gestion de ces équipements. C’est ce à quoi les services techniques de la ville aimeraient pouvoir s’atteler prochainement.

Est-il possible d’avoir une maîtrise complète de sa solution d’interphonie, déployée sur des sites très différents dans la ville, en s’appuyant sur des logiciels libres existants et sur une infrastructure robuste et sécurisée ? Et si possible avec une variété de matériels et de constructeurs ?

Joie ! La réponse semble bien être positive, et c’est ce que je me propose de vous présenter lors de l’événement Open Source Experience, au Palais des Congrès (porte Maillot) à Paris, le 4 décembre 2024 à 15h salle Alan Cox.

Image d’illustration : Bernard Hermant sur Unsplash

[NDT] Des années. Des années que j’explique que la complexité des mots de passe n’est pas déterminante et que demander de les changer à intervalles réguliers est une mauvaise idée. Enfin, un organisme officiel qui publie des recommandations conformes aux enjeux du moment (et qui ne datent pas d’hier).

Ce contenu est une traduction d’un article de Guru Baran paru le 27 septembre 2024 sur le site cybersecuritynews.com.

***

Le National Institute of Standards and Technology (NIST) a publié des lignes directrices actualisées pour la sécurité des mots de passe, marquant un changement important par rapport aux pratiques traditionnelles en matière de mots de passe.

Ces nouvelles recommandations, décrites dans la « publication spéciale 800-63B » du NIST, visent à renforcer la cybersécurité tout en améliorant l’expérience des utilisateurs.

L’un des changements les plus notables concerne la position du NIST sur la complexité des mots de passe. Contrairement aux pratiques de longue date, le NIST ne recommande plus l’application d’exigences arbitraires en matière de complexité des mots de passe, telles que le mélange de lettres majuscules et minuscules, de chiffres et de caractères spéciaux. L’accent est désormais mis sur la longueur du mot de passe, qui constitue le principal facteur de solidité du mot de passe.

« Les mots de passe plus longs sont généralement plus sûrs et plus faciles à retenir pour les utilisateurs », a déclaré Paul Turner, expert en cybersécurité au NIST. « Nous nous éloignons des règles complexes qui conduisent souvent à des schémas prévisibles et nous encourageons l’utilisation de phrases de passe longues et uniques ».

Le NIST recommande désormais une longueur de mot de passe minimale de 8 caractères, avec une forte préférence pour les mots de passe encore plus longs. Il est conseillé aux organisations d’autoriser des mots de passe d’au moins 64 caractères pour tenir compte des phrases de passe.

Un autre changement important est l’élimination des changements périodiques obligatoires de mots de passe. Le NIST affirme que les réinitialisations fréquentes de mots de passe conduisent souvent à des mots de passe plus faibles et encouragent les utilisateurs à effectuer des changements mineurs et prévisibles. Au lieu de cela, les mots de passe ne devraient être changés que lorsqu’il y a des preuves de compromission.

« Forcer les utilisateurs à changer régulièrement de mot de passe n’améliore pas la sécurité et peut même s’avérer contre-productif », explique M. Turner. « Il est plus efficace de surveiller les informations d’identification compromises et de n’exiger des changements qu’en cas de nécessité ».

Les nouvelles lignes directrices soulignent également l’importance de vérifier les mots de passe par rapport à des listes de mots de passe couramment utilisés ou compromis. Le NIST recommande aux organisations de tenir à jour une liste de mots de passe faibles et d’empêcher les utilisateurs de choisir le moindre mot de passe figurant sur cette liste.

En outre, le NIST déconseille l’utilisation d’indices de mots de passe ou de questions d’authentification basées sur la connaissance, car ils peuvent souvent être facilement devinés ou découverts par l’ingénierie sociale.

Pour le stockage des mots de passe, le NIST recommande d’utiliser le hachage salé avec un facteur d’inviolabilité qui rend les attaques hors ligne coûteuses en termes de calcul. Cette approche permet de protéger les mots de passe stockés même si une base de données est compromise.

Autres exigences à respecter :

1. Les responsables et fournisseurs de services DOIVENT exiger que les mots de passe comportent au moins huit caractères et DEVRAIENT exiger que les mots de passe comportent au moins 15 caractères.
2. Les responsables et fournisseurs de services DEVRAIENT autoriser une longueur maximale de mot de passe d’au moins 64 caractères.
3. Les responsables et fournisseurs de services DEVRAIENT accepter tous les caractères d’imprimerie ASCII [RFC20] et le caractère espace dans les mots de passe.
4. Les responsables et fournisseurs de services DEVRAIENT accepter les caractères Unicode [ISO/ISC 10646] dans les mots de passe. Chaque point de code Unicode DOIT être considéré comme un seul caractère lors de l’évaluation de la longueur du mot de passe.
5. Les responsables et fournisseurs de services NE DOIVENT PAS imposer d’autres règles de composition (par exemple, exiger des mélanges de différents types de caractères) pour les mots de passe.
6. Les responsables et fournisseurs de services NE DOIVENT PAS exiger des utilisateurs qu’ils changent périodiquement de mot de passe. Toutefois, les vérificateurs DOIVENT imposer un changement s’il existe des preuves de la compromission du service.
7. Les responsables et fournisseurs de services NE DOIVENT PAS permettre à l’abonné de stocker un indice accessible à un demandeur non authentifié.
8. Les responsables et fournisseurs de services NE DOIVENT PAS inviter les abonnés à utiliser l’authentification basée sur les connaissances (KBA) (par exemple, « Quel était le nom de votre premier animal de compagnie ? ») ou des questions de sécurité lors du choix des mots de passe.
9. Les fournisseurs de services DOIVENT vérifier l’intégralité du mot de passe soumis (c’est-à-dire ne pas le tronquer).

Les lignes directrices soulignent également l’importance de l’authentification multifactorielle (AMF) en tant que couche de sécurité supplémentaire. Bien qu’il ne s’agisse pas d’une exigence directe en matière de mot de passe, le NIST encourage vivement l’utilisation de l’AMF dans la mesure du possible.

Ces nouvelles recommandations ont été bien accueillies par de nombreux acteurs de la communauté de la cybersécurité. « Les directives actualisées du NIST sont conformes à ce que les chercheurs en sécurité préconisent depuis des années », a déclaré Sarah Chen, directrice technique de SecurePass, une société spécialisée dans la gestion des mots de passe. « Elles établissent un bon équilibre entre la sécurité et la facilité d’utilisation.

Au fur et à mesure que les organisations mettent en œuvre ces nouvelles lignes directrices, les utilisateurs peuvent s’attendre à voir des changements dans les politiques de mots de passe sur diverses plateformes et services. Bien qu’il faille un certain temps pour que tous les systèmes s’adaptent, les experts pensent que ces changements conduiront à une sécurité des mots de passe plus efficace à long terme.

Le NIST souligne que ces lignes directrices ne s’adressent pas uniquement aux agences fédérales, mais qu’elles constituent des pratiques exemplaires pour toutes les organisations concernées par la cybersécurité.

Les cybermenaces ne cessant d’évoluer, il est essentiel de se tenir au courant des dernières recommandations en matière de sécurité pour protéger les informations et les systèmes sensibles.

Image d’illustration : Debby Hudson sur Unsplash.

Organiser un échange n’est pas toujours simple et nécessite parfois plusieurs allers-retours, chacun indiquant ses disponibilités avant de trouver un créneau commun. C’est là qu’intervient cal.com.

Cal.com est une plateforme de planification open-source qui facilite la gestion des rendez-vous et des réunions. Elle permet aux utilisateurs de synchroniser leurs calendriers existants pour éviter les conflits d’horaire et simplifier la prise de rendez-vous. Une version en ligne existe, qui permet de tester la solution. Elle se trouve ici. Elle est gratuite pour les particuliers, et certaines fonctionnalités ne sont disponibles qu’en version payante : gestion d’équipes, personnalisation au nom de la société, etc.

Pourquoi cal.com ?

Cette solution a un énorme avantage : si elle sait gérer la plupart des agendas du marché (Microsoft, Google, etc), elle supporte aussi CalDav, un protocole standard généralement intégré dans les solutions de messagerie/calendrier open source. C’est, en partie, ce qui a motivé notre choix.

La version gratuite en ligne peut vous permettre de tester le logiciel et ses nombreuses fonctionnalités, mais elle n’est pas utilisable dans un cadre professionnel. Pour des questions de licence, bien sûr, mais aussi parce que, pour vérifier vos disponibilités et prendre des rendez-vous, cal.com va devoir accéder en écriture à votre agenda professionnel. On conçoit aisément ce qu’enregistrer identifiants et mots de passe professionnels sur un site géré par on-ne-sait-qui peut avoir de problématique.

Heureusement, cal.com est open source est peut-être installé sur un serveur en local (sources ici). Il repose sur Node.js et React. Il intègre la gestion d’équipe (c’est à dire la vérification des disponibilités dans plusieurs calendriers) en mode global (tout le monde doit être disponible pour qu’un rendez-vous soit possible) ou « round robin » (si une personne de l’équipe est disponible, un rendez-vous est proposé).

Limites et points d’attention

• Pour pouvoir bénéficier, en toute confidentialité, des fonctionnalités de la solution, il convient de la déployer sur un serveur sûr. Un hébergement maîtrisé est donc nécessaire, puisque qu’elle va accéder en écriture à votre solution d’agenda interne.

• Des compétences sont nécessaires pour installer et maintenir la solution. Si celles-ci ne sont pas disponibles dans la structure, une prestation de service peut s’avérer utile (mais peut-être coûteuse).

• L’authentification sur cal.com est locale : l’intégration à l’annuaire professionnel (OpenLdap, Active Directory) n’est pas prévue.

• La personnalisation de l’outil n’est pas simple : à Échirolles, l’affichage du logo se fait par une redirection nginx.

Cas d’usages

À Échirolles, nous utilisons cal.com dans trois types de cas :

• La prise de rendez-vous individuels
  
  Définissez les périodes pendant lesquelles cal.com va pouvoir vous placer des rendez-vous (les après-midi seulement, par exemple). Le logiciel vérifie vos disponibilités dans votre agenda sur ces périodes seulement. Un formulaire en ligne permet d’organiser le rendez-vous. Configurable il peut, par exemple, intégrer un lien de visio. Une invitation par mail est envoyée à la personne qui souhaite vous rencontrer, et l’événement est ajouté à votre calendrier (moyennant, éventuellement, une confirmation de votre part)

• La réservation de salles de réunion
  
  Facilement intégrable dans un intranet, cal.com permet de réserver une des salles de réunion de la ville, chacune disposant de son propre agenda dans notre messagerie SOGo. Deux types de réservation sont possibles :
  • Une salle de réunion au hasard (en vérifiant les disponibilités de l’ensemble des salles)
  • Une salle de réunion en particulier (en accédant à ses disponibilités particulières)

• L’organisation de formations internes
  
  cal.com sait gérer un nombre de places, et permet donc de limiter le nombre de personnes qui vont pouvoir s’inscrire à un événement. En lien avec la salle dédiée à la formation, il est utilisé, via notre intranet, pour organiser nos formations en interne. Chaque personne qui s’inscrit reçoit un lien d’invitation et, sur l’agenda dédié à la formation, la liste des participants est mise à jour au fur et à mesure.

Pour plus d’informations, n’hésitez pas à me contacter sur Mastodon.

La veille technologique fait partie des missions de tout responsable informatique. Elle repose sur une bonne connaissance et une consultation régulière de de ressources disponibles en ligne, mais pas seulement. Il n’est pas rare que les usages évoluent au sein de la structure et que nous découvrions, en échangeant avec nos utilisateurs, de nouveaux outils. Problème : ils ne correspondent pas toujours aux recommandations du service informatique, sont parfois incompatibles avec le RGPD ou peuvent poser des problèmes de confidentialité (ou de sécurité).

La politique de la ville d’Échirolles privilégie l’utilisation de logiciels libres et une gestion responsable des données. Il est donc de notre devoir, quand un logiciel n’est pas compatible avec notre schéma directeur « Échirolles numérique libre »., de nous en préoccuper. Mais ces solutions naissent dans notre système d’information parce qu’elles correspondent à un besoin non couvert ou que les utilisateurs considèrent comme plus simple/plus efficace, etc. Interdire l’utilisation n’est donc pas satisfaisant du point de vue du service rendu : il convient de se mettre à la recherche d’alternatives qui sont mieux adaptées au projet de la structure.

Depuis quelques années, Canva est apparu dans nombre d’entreprises et de collectivités, son utilisation est rapidement devenue massive. Nous nous sommes donc mis à la recherche d’une solution crédible, open source, et qui permettrait d’apporter une réponse au besoin de nos employés. Il en existe de nombreuses, et le benchmarking n’a pas été simple. Mais une solution a fini par s’imposer :

Polotno

Polotno se présente comme un clone de Canva. Il permet la création de présentations, posters ou création graphiques en local. Aucun compte n’est nécessaire et les productions ne sont pas conservées sur le serveur.

Il partage avec la solution propriétaire une interface simple et intuitive, l’accès direct à d’immenses bases de données d’icônes (Iconfinder et Noun Project), de photographies (Unsplash), et de nombreux modèles graphiques ou textuels.

Une version en ligne existe à l’adresse studio.polotno.com. Les créations sont conservées localement dans le cache du navigateur, ce qui est plutôt une bonne chose du point de vue de la confidentialité mais qui ne facilite pas le travail en équipe. En revanche, la possibilité d’exporter les créations (en format JSON) avec l’ensemble des éléments (photos, polices, etc.) permet de les transmettre facilement, et de les sauvegarder.

Petit couac : cette version en ligne est mal traduite en français et l’utilisateur est encouragé à créer un compte (payant) sur un cloud en ligne pour sauvegarder son travail. Heureusement, il s’agit d’un logiciel open source. Le code est accessible sous licence MIT. Nous avons donc fait le choix de créer une instance échirolloise de Polotno, correctement traduite et expurgée de ces éléments commerciaux.

J’en ai également installé une, auto-hébergée, pour mon usage personnel. Vous pouvez la tester en cliquant ici.

Quelques éléments ne sont pas encore à la hauteur (impossibilité, dans le module texte, de créer des listes), mais le logiciel évolue rapidement et les mises à jour apportent régulièrement des améliorations.

Sur la gestion des données personnelles par Canva (en anglais) :

• Data Processing Addendum
• Canva list of sub-processors

Source image d’illustration : Roméo A. sur Unsplash (recadrée avec Polotno)

Ce texte est une reprise d’un article issu du site de l’April, dont l’original est consultable ici.

***

La Cour des comptes a ouvert, jusqu’au 4 octobre 2024, une plateforme de consultation afin de permettre à celles et ceux qui le souhaitent de proposer des thèmes nouveaux sur lesquels l’institution pourrait exercer sa mission de contrôle de l’action publique. L’April y propose « L’évaluation des dépenses logicielles de l’État et des administrations centrales »

En 2022, la Cour des comptes avait initié le principe de consultation publique dans l’objectif de « renforcer les liens des juridictions financières avec les citoyennes et citoyens ». La consultation qui se tient actuellement, et jusqu’au 4 octobre, est donc la troisième édition.

Lors de la première consultation, l’April avait soutenu une proposition de Stéfane Fermigier, coprésident du CNLL (Union des entreprises du numérique ouvert), pour « évaluer les dépenses de logiciels et services en ligne des administrations centrales ». Une proposition dont l’ambition est de couvrir le plus large spectre possible des dépenses informatiques de l’État, notamment en ventilant ces dépenses selon plusieurs critères (type d’acquisition, type de logiciels, taille des fournisseurs, etc.). Une telle évaluation serait en effet bienvenue pour mieux appréhender la réalité des dépendances de l’État à certaines solutions privatrices, et en tout état de cause, un prérequis à la mise en œuvre d’une politique un tant soit peu ambitieuse pour un plus grand usage du logiciel libre au sein des administrations publiques.

La Cour des comptes elle-même considère d’ailleurs, dans un récent rapport de juillet 2024 sur le pilotage de la transformation numérique de l’État 1, qu’« une véritable stratégie numérique avec des objectifs et jalons ne peut faire l’économie d’une consolidation, actuellement inexistante, des dépenses numériques de l’État et de leur projection. »

L’April s’est donc faite sienne cette proposition et la soumise à nouveau lors de cette troisième consultation.

La plateforme de la consultation précise quelques étapes : après la consultation, d’octobre à novembre, les contributions seront analysées et une synthèse sera produite pour, notamment, mettre en valeur les sujets ayant suscité les plus d’interactions, ainsi que les propositions les plus argumentées. En janvier, les sujets de contrôle seront annoncés et la synthèse des contributions sera rendue publique. Les contrôles seront ensuite lancés à partir de janvier. Enfin, en septembre 2025, la quatrième campagne de participation citoyenne sera lancée.

Nous invitons toute personne soucieuse d’une meilleure prise en compte du logiciel libre par la puissance publique à soutenir, voire à commenter, la contribution de l’April.

→ Cliquez ici pour vous rendre sur le site de l’April et soutenir cette importante initiative.

Source de l’image d’illustration : Agence Olloweb sur Unsplash

Selon Wikipédia, « La résistance (ou aversion) au changement ou immobilisme, consiste à désirer, et tenter d’obtenir par diverses formes de comportements d’opposition, le maintien du statu quo par procrastination ». Michel Crozier, sociologue des organisations (et grand ami du capitalisme triomphant), la définit comme « l’expression raisonnable et légitime des risques que comporte le changement pour les acteurs », introduisant deux notions (raisonnable et légitime) qu’il n’est pas inutile d’interroger : dans un contexte de transition subie (le dérèglement climatique, par exemple), la résistance est-elle raisonnable et légitime ?

Cette problématique de la résistance au changement n’est donc pas spécifique au numérique : elle est un frein, plus ou moins puissant, à toute évolution, toute remise en cause d’un ordre existant.

Alors comment expliquer qu’elle soit si prégnante dans les projets de passage aux logiciels libres ? En réalité, elle se pose de la même façon pour les logiciels propriétaires, mais elle est prise en compte depuis très longtemps. Un passage direct de Windows 95 à Windows 11, par exemple, serait vécu comme une catastrophe par la plupart des utilisateurs. Mais les changements introduits dans le fonctionnement, dans l’ergonomie et dans l’expérience utilisateur en général ont été suffisamment progressifs pour que la résistance soit contenue à des niveaux acceptables.

Changement progressif, facteur temps, introduction de nouvelles fonctionnalités, communication, mimétisme, accoutumance lors de la formation, il y a des leçons à retenir dans la façon de procéder de ces acteurs privés qui, aujourd’hui, se sont imposés comme une évidence auprès des utilisateurs que nous sommes.

Et puis un rappel : l’objectif prioritaire d’un service informatique ne peut pas être de mettre en place les logiciels libres. La priorité, c’est de mettre à la disposition des services/départements les meilleurs outils pour qu’ils puissent effecteur convenablement les tâches qui leur sont confiées.

Les types de résistants

La configuration idéale est celle dans laquelle gouvernance, service informatique et utilisateurs sont acteurs du projet. Mais plus la structure est de taille importante et moins celle-ci est probable, évidemment.

 Les gestionnaires et décideurs⋅euses : souvent responsables de l’approbation des décisions d’achat de logiciels, ils peuvent avoir des préoccupations concernant la viabilité et la stabilité des solutions open source, en particulier si elles sont habituées à travailler avec des fournisseurs de logiciels propriétaires bien établis. Les questions de support et de responsabilité peuvent également être un facteur : il peut y avoir une perception de risque plus élevé associé à l’utilisation de logiciels sans garantie ou soutien formel.

 Les services informatiques : il n’est pas rare que les professionnel⋅les de l’informatique, en charge de la mise en œuvre et de la maintenance des logiciels expriment des réserves. Ils/elles peuvent être préoccupé⋅es par les problèmes de compatibilité, craignant que les logiciels libres ne fonctionnent pas bien avec les systèmes existants. Il y a aussi parfois une perception que les logiciels open source sont moins sécurisés ou plus difficiles à prendre en charge, ce qui peut conduire à des inquiétudes quant à la charge de travail supplémentaire ou aux risques potentiels pour la sécurité. Un changement peut également être vécu comme une remise en cause des compétences de l’équipe, et un bouleversement d’une certaine « hiérarchie » basée sur les connaissances.

 Les utilisateurs⋅trices : il s’appuient sur les logiciels au quotidien et peuvent légitimement s’inquiéter, en particulier s’ils sont habituées à un logiciel propriétaire spécifique et se sentent à l’aise dans son utilisation. L’apprentissage d’un nouveau système peut sembler intimidant et certain⋅es utilisateurs⋅trices peuvent craindre que le logiciel open source soit plus complexe ou moins convivial.

 Les fournisseurs de logiciels propriétaires : les entreprises qui vivent des logiciels propriétaires peuvent également résister au passage à des solutions libres. Ils reprennent parfois des lieux communs ou idées reçues pourtant éculées. Il n’est pas inhabituel qu’ils exagèrent les risques associés aux logiciels open source pour protéger leurs intérêts commerciaux. Ces fournisseurs peuvent parfois avoir des relations bien établies avec les organisations et influencer défavorablement décideurs et utilisateur.

Deux situations sont fréquentes :

La gouvernance est à l’origine du projet mais le service informatique pour des raisons variables, ne met pas en oeuvre.

 Si le manque de compétence dans l’équipe est en cause mais que la volonté de déployer existe, un effort d’accompagnement (formation et communication) est nécessaire avant d’entamer le projet. Car faire mal est pire que de ne pas faire : cela peut décourager durablement les utilisateurs⋅trices et inscrire, dans les esprits, un lien direct entre logiciel libre et mauvais fonctionnement.

 Si l’équipe n’est pas convaincue que le changement est une bonne idée, la situation se complique mais elle n’est pas désespérée pour autant. La solution : une attention particulière portée aux profils recrutés. Chaque opportunité de recrutement peut/doit se concrétiser par l’embauche d’un employé qui a des compétences et une appétence et pour les logiciels libres. Cela peut certes prendre du temps, mais sans ce virage dans le positionnement, il y a de fortes chances que le projet soit voué à l’échec, soit parce que le travail ne sera pas fait, soit (et c’est pire) parce qu’il sera mal fait.

Le service informatique est moteur, sans soutien de celles et ceux qui ont le pouvoir de décision.

Plusieurs approches sont possibles dans ce cas :

 échanger sur les avantages des logiciels libres. Inutile de mettre en avant une litanie d’arguments, aussi pertinent soient-ils. On ne fait pas de logiciel libre pour le plaisir d’en faire, mais pour mieux répondre à un besoin, à une thématique qu’on souhaite adresser. Mieux vaut donc cibler le discours en fonction des préoccupations de celle ou celui qui doit prendre la décision : souveraineté numérique et propriété intellectuelle, respect des données personnelles, économies, cybersécurité, stabilité et vitesse de réaction, sobriété numérique, vendor locking évité, correspondance avec les valeurs de la structure, les angles d’approche sont nombreux. Prenez le temps de bien les connaître et de construire un argumentaire, écrit ou oral, qui s’appuie sur ceux qui seront partagés par vos interlocuteurs⋅trices.

 choisir de ne pas parler d’open source et de logiciels libre : axer tout le discours sur l’adéquation de la solution proposée avec le besoin identifié. Si la question est posée, l’évacuer rapidement. Cela peut également s’appliquer aux utilisateurs⋅trices : la priorité est de leur donner les moyens de faire leur travail dans de bonnes conditions, et le choix du libre peut tout à fait ne pas être mis en avant.

Les types de résistance

 Familiarité et confort : les gens ont tendance à résister au changement lorsqu’ils sont à l’aise et habitués à un système existant. Plus un logiciel leur semble simple et efficace et plus leur inquiétude sera grande. Certain-es ont dû fournir un effort conséquent pour disposer des compétences leur permettant de s’acquitter de leurs tâches quotidiennes. L’apprentissage d’un nouveau logiciel peut leur sembler intimidant et le simple fait d’utiliser une interface différente peut être mal vécu.

 Pression culturelle : certaines professions sont intimements liées, dès la période de formation, à des solutions propriétaires. Les graphistes, par exemple, sont en immense majorité des utilisateurs⋅trices de Macintosh et de la suite de création graphique d’Adobe.

 Compatibilité et intégration : les organisations ont souvent des systèmes complexes et des processus parfois bien établis. Les problèmes de compatibilité ou de difficultés d’intégration avec les systèmes existants, réels ou supposés, sont souvent évoqués comme un frein au changement.

 Peur du déclassement : passer d’un système couramment utilisé à un environnement plus inhabituel peut être vécu comme un déclassement, une dégradation des conditions de travail. Pour celles et ceux qui sont sensibles à cette crainte, la gratuité ou la singularité de l’outil sont autant d’indices d’un fonctionnement moins qualitatif. La peur de la marginalisation, de la différence, sont des moteurs puissants de la résistance.

 Peur de revivre une migration mal gérée : un projet de migration vers un logiciel libre, annoncé, revendiqué et qui se passe mal peut avoir des effets terribles pour le futur. L’utilisateur⋅trice associe presque systématiquement « open source » (ou logiciel libre) et dysfonctionnement.

Les moyens d’avancer : une stratégie de migration claire, adaptée, systématique… et souple.

Une stratégie de migration efficace doit prendre en compte l’ensemble de ces situations et les adresser, sous peine de courir à l’échec. On peut être compétent, convaincu de l’utilité, de l’intérêt ou de l’urgence de choisir une autre voie dans la mise en oeuvre du numérique et échouer. Ces convictions, que je partage, n’ont pas leur place dans une stratégie de migration. Au contraire, elles peuvent faire obstacle à une écoute attentive et à la prise en compte des craintes exprimées (directement ou indirectement) par les utilisateurs⋅trices. Méfions nous de notre enthousiasme et partons du principe qu’il est rarement partagé.

Mais foin des considérations théoriques et autres déclarations péremptoires, voici un exemple de projet de migration (à Linux, pour l’exemple) qui prendrait justement, et dans la mesure du possible, en compte les écueils évoqués.

Le choix du meilleur outil

Avant d’entamer la migration, un important travail de préparation doit être réalisé, en interne. Il permet de :

 vérifier que l’outil (la distribution de Linux, par exemple) s’intègre parfaitement dans l’environnement informatique tel qu’il est (et pas tel qu’on aimerait qu’il soit). Cette intégration avec l’existant s’appréhende de manière étendue, pour garantir la compatibilité avec les systèmes communs (annuaire informatique, systèmes d’impression, serveur de fichier, etc.) et l’ensemble des logiciels utilisés au quotidien. Cela suppose une bonne connaissance des besoins métiers et habitudes prises sur les postes clients.

 sélectionner une distribution qui se rapproche le plus possible de ce que les gens connaissent déjà (Windows ou MacOS, typiquement). Cela permet de minimiser l’impression d’un changement important… et donc l’effort de formation nécessaire pour une adoption en douceur. Un passage de Windows 11 à Ubuntu sera toujours plus difficile qu’un passage à Zorin OS, distribution qui s’efforce justement de ressembler à Windows.

 négocier, avec les décideurs⋅euses, une migration qui ne s’appuie sur aucun d’objectif chiffré, ni daté. Cette condition permet d’adapter l’effort de migration au niveau de résistance rencontré. Elle donne au service la latitude de réagir en cas de problème, de monter progressivement en compétence et de fournir aux utilisateurs⋅trices un niveau de service à la hauteur de l’importance du projet. Un objectif de migration à 100% est illusoire, et il faut l’affirmer dès le début du projet. Des problèmes de compatibilité (avec des solutions fournies par des partenaires, par exemple) peuvent se présenter et compromettre la migration de certains utilisateurs. La résistance culturelle peut également être si forte que, dans certains cas, renoncer est la meilleure des solutions.

 prévoir des solutions de contournement : des problèmes d’incompatibilité avec des logiciels métier peuvent se poser, qu’il ne faut pas négliger. Envisager des moyens de les faire fonctionner est indispensable sous peine d’impacter sérieusement la migration. Un accès à un serveur RDP sous Windows permet, avec le client Remmina pour Linux, de résoudre énormément de ces cas (logiciels avec client lourd pour Windows, accès à Excel dans le cas d’incompatibilité avec des solutions tierces, etc.)

 prévoir une communication sur le sujet : partager la stratégie de migration, préciser que l’objectif n’est pas de passer tout le monde au libre, affirmer qu’il n’y aura pas de migration contrainte, penser à mettre en avant les « petits plus » et les avantages (pour les utilisateurs⋅trices, pas pour la gouvernance) du changement, bref : rendre, autant que possible, le changement désirable.

Une expérimentation à petite échelle

Dans les premiers temps de la migration, il est indispensable de limiter le nombre de postes concernés, et de s’adresser à un public choisi. Ce beta-test permet de réaliser les derniers ajustements et de s’assurer qu’en condition opérationnelle il répond effectivement au besoin, avec le niveau de qualité attendu. Sur un parc de 500 utilisateurs⋅trices il peut concerner, par exemple, une dizaine de personnes. On prendra soin de sélectionner des profils d’utilisation variés, et d’intégrer plusieurs décideurs⋅euses-clés (pour une validation facilitée du passage aux étapes suivantes).

Un appel au volontariat

La meilleure façon d’entamer effectivement la migration est de commencer par un appel au volontariat. « Vous voulez utiliser Linux ? Nous l’installons et nous le maintenons ! ». Cette étape a plusieurs vertus. Elle permet :
 d’augmenter le parc installé sans résistance au changement (ou avec une résistance très faible). Cela participe de la montée en compétence progressive de l’équipe ;
 faire naître la nouvelle solution dans l’environnement informatique de la collectivité ou de l’entreprise. Le simple fait qu’une utilisation de Linux au quotidien apparaisse dans les usages permet de lever un certain nombre de doutes sur la faisabilité d’une évolution ;
 pouvoir communiquer sur une migration effectivement démarrée.

Dans mes différentes expériences, cette phase (additionnée au beta-test), maintenue pendant 1 an, a permis de migrer 5% du parc environ.

Une phase d’incitation

Proposer systématiquement Linux lors de la remise d’une nouvelle machine permet également de faire exister la solution et d’élargir le champ des possibles sans contrainte pour les employé⋅es. Après une phase d’appel au volontariat, cela permet d’équiper des gens qui ont vu fonctionner Linux chez d’autres, ont pu en mesurer certains des avantages et ont développé une curiosité pour le sujet.

Cette phase permet d’installer l’utilisation de Linux comme une alternative crédible au sein de la structure et de l’asseoir, au niveau du service informatique, dans un fonctionnement standardisé. Après quelques années (2 à 3 ans, typiquement), 10% à 20% du parc peut ainsi être migré.

Le libre par défaut ?

Si les phases précédentes se sont globalement bien déroulées et que la présence de postes clients sous Linux n’est plus une surprise dans l’environnement de la structure, pourquoi ne pas en faire le système d’exploitation par défaut ?

Dans ce cas, il faut garder à l’esprit que certains postes, pour les raisons exposées ci-dessus, ne pourront/devront pas être migrés :

 parce que des logiciels métiers peuvent être vraiment incompatibles avec Linux ;
 parce que la résistance culturelle est trop forte. Il convient de garder à l’esprit que, pour certaines professions (les graphistes, typiquement), une migration à Linux peut être socialement très coûteuse. Leur demander de changer nécessite un effort de formation énorme (ceux qui comme moi ont fait l’effort de passer de Photoshop à GIMP comprendront de quoi je parle) et peut leur donner le sentiment, conscient ou pas, d’une marginalisation importante dans leur milieu (alors même qu’il n’y a pas d’obstacles techniques et fonctionnels objectifs). S’il n’est pas inintéressant de travailler le sujet quand c’est possible, il ne faut certainement pas commencer par adresser ces populations. Renoncer peut même être sage.

L’accompagnement, la formation

Si une bonne stratégie de migration permet de minimiser l’effort de formation nécessaire pour le passage à une solution libre, c’est un point qu’il ne faut pas négliger. Prévoir des sessions de formation permet de répondre à plusieurs types de demandes :
 des demandes de montée en compétence (pour une utilisation plus ou moins avancée) ;
 des inquiétudes liées à la nouveauté (alors que le niveau de la personne est suffisant pour pouvoir fonctionner en autonomie). Ce deuxième point est important : au delà des aspects techniques, la formation est vécue comme un moment d’échange et d’écoute avec ceux qui ont proposé (et qui mettent en oeuvre) le changement. Elle est l’affirmation que le service a conscience de ce qui peut parfois être perçu (à tort ou à raison) comme un effort important.

Le positionnement doit être : comment puis-je faire sous Linux (ou avec LibreOffice, par exemple), ce que je sais déjà faire sous Windows (ou sous Microsoft Office) ? Partir, en complément d’une formation générale, d’exemple concrets fournis par les employé⋅es et travaillés ensemble, est une très bonne idée.

De nombreux⋅ses acteurs et actrices de l’écosystème peuvent vous aider à mettre en oeuvre, en lien avec le service des ressources humaines, des prestations d’accompagnement et/ou de formation. Vous pouvez aussi faire le choix, si la charge de travail de l’équipe le permet, de sessions organisées en interne.

L’échange avec les autres acteurs

Échanger avec des collègues qui ont déjà dû gérer une migration de ce type est une très bonne idée. Cela permet de s’inspirer de pratiques et d’outils qui ont fait la preuve de leur efficacité dans un contexte approchant. Des écueils importants et de nombreuses fausses bonnes idées peuvent être utilement évités. Des noms de prestataires qui ont donné satisfaction peuvent également être partagés.