C’est un principe de base de la bonne gestion d’une collectivité : l’investissement crée de la valeur durable, alors qu’une hausse des charges de fonctionnement consomme des ressources chaque année sans enrichir le patrimoine communal. C’est la raison pour laquelle le recours à l’emprunt pour alimenter le budget de fonctionnement est interdit. C’est aussi pour cela que les collectivités recherchent en permanence des pistes d’économies en coûts de fonctionnement.

Par l’utilisation massive du mode SaaS, du cloud, des licences logicielles et des contrats de maintenance ou de support, l’écosystème numérique impacte directement, et de façon toujours plus importante, ce budget de fonctionnement que nous essayons à toute force de maîtriser.

Le passage aux logiciels libres, quand il s’accompagne d’un effort de ré-internalisation des compétences et d’une politique volontaire d’auto-hébergement des solutions, est de ce point-de-vue là particulièrement vertueux. Associé à une politique de recrutement et une réorganisation favorisant les compétences techniques et l’autonomie du service, il transforme, petit à petit, des coûts de fonctionnement en investissements.

Quelques exemples à Échirolles (*) :

La diffusion en direct du conseil municipal

Le projet a nécessité l’achat de 3 caméras-tourelles et d’un switch POE pour un montant d’environ 6 000 €.

La solution a été installée et paramétrée par la DSI. La diffusion est assurée depuis un PC sous Linux avec le logiciel libre OBS Studio, configuré avec le protocole NDI (pour l’intégration temps réel du son et de l’image) et le plugin PTZ Control (pilotage des caméras depuis la régie).

Diffusé sur le serveur Peertube de la ville et intégré sur le site web de la ville, il est réalisé par un agent du service communication. Le rendu est de qualité, avec affichage de la date, de l’heure, du nom de l’élu rapporteur et de la délibération. La solution est d’une simplicité et d’une stabilité rares, sans aucun problème technique depuis plus de 4 ans. L’intégration de la visioconférence, basée sur le logiciel BigBlueButton de la collectivité, a été pensée pour permettre une prise de parole à distance si nécessaire.

Si d’autres collectivités ont fait le choix de s’appuyer sur des prestataires et, parfois, de louer le matériel, avec un impact important sur le budget de fonctionnement, l’achat de matériel, l’utilisation de logiciels libres et la réalisation en interne ont permis de mettre en place cette solution de qualité pour un total de 6 000 €, un investissement facilement amorti.

L’affichage de l’information municipale

5 écrans diffusent en direct, partout dans la ville, l’information municipale rédigée par le service communication.

Dans le hall d’accueil de l’hôtel de ville, cette présentation alterne avec une représentation graphique, en temps réel, de la production électrique des panneaux solaires qui se trouvent sur le toit du bâtiment. Dans les 4 maisons des habitant⋅es de la ville, la communication municipale est également diffusée, en alternance avec des informations propres à chaque établissement.

Cette solution, conçue en interne, repose sur des PC fixes sous Linux (des mini-tours) reconditionnés par le service. La partie logicielle est un triptyque Debian server/Openbox/Openkiosk, des logiciels libres connus pour leur légèreté et leur stabilité. Les mises à jour sont automatiques (unattended-upgrade). Chaque écran démarre en quelques secondes et la présentation est mise à jour depuis slides.com, le site vitrine du mainteneur de reveal.js, un logiciel libre également. Meshcentral, le logiciel libre de gestion quotidienne du parc utilisé à Échirolles, permet de prendre la main sur n’importe quel écran et apporter un soutien technique en cas de besoin. Grâce à la fonctionnalité de partage de slides.com, le service communication peut apporter son aide à chacune des structures pour ce qui concerne le contenu.

Simple et fiable, ce service repose sur l’achat des écrans et, quand c’est nécessaire, une prestation de câblage pour la connexion réseau. Des investissements durables et rapidement amortis.

Ces deux exemples (il y en a de nombreux autres) illustrent comment, par un pilotage stratégique fin, l’utilisation de logiciels libres et la réalisation des projets en interne, il est possible de mettre en place des solutions avancées sans oblitérer le budget en fonctionnement de la collectivité.

L’utilisation de logiciels libres permet de transformer des coûts de fonctionnement en investissements durables et participe de façon significative à la maîtrise budgétaire de la collectivité.

(*) Ces solutions ont fait l’objet d’une publication sur le site public de documentation de la ville : https://documentation.echirolles.fr.

Image d’illustration : Photo de Towfiqu barbhuiya sur Unsplash

Dans un écosystème numérique dominé par quelques grands fournisseurs mondiaux, la question de la souveraineté technologique et de la maîtrise de ses dépendances est devenue stratégique pour les Directions des Systèmes d’Information (DSI). Pourtant, toutes les dépendances ne se valent pas, et toutes ne peuvent pas être réduites avec le même effort ou la même efficacité. L’enjeu pour le DSI n’est donc pas seulement de réduire les dépendances, mais de hiérarchiser ses actions selon son pouvoir réel d’agir.

La dépendance au matériel, par exemple, est épisodique (bien que régulière) et est une problématique d’approvisionnement : une fois équipé, il n’y a plus véritablement de dépendance, le matériel vous appartient. Une dépendance à Microsoft Office 365 est d’un autre niveau ; elle est immédiate, permanente mais aussi réversible ; des alternatives nombreuses existent, ici et maintenant.

Comment prioriser et s’y retrouver dans les domaines sur lesquels on peut agir ?

La tâche peut sembler ardue, voire désespérante, et il n’est pas rare que l’action soit paralysée par le constat d’un niveau de dépendance tellement élevé et multifactoriel qu’on ne sait par quel bout entamer la transformation. Ce petit guide a pour objectif d’éclaircir un peu la problématique.

1. Identifier les niveaux de dépendance

Avant de définir une stratégie, il peut être utile d’établir une cartographie des dépendances. Cette cartographie peut inclure les catégories suivantes :

• Infrastructures matérielles et réseau mondial : processeurs, mémoire, fibres optiques, câbles sous-marins, liaisons intercontinentales.
  → Zone d’action quasi nulle pour une DSI : ces dépendances sont globales et structurelles.

• Ressources énergétiques et logicielles verticales : alimentation électrique, refroidissement, outils métiers propriétaires.
  → Zone d’action limitée : il est parfois possible de négocier, d’optimiser, ou de diversifier, mais rarement de remplacer totalement.

• Couches logicielles et infrastructurelles : systèmes d’exploitation, bases de données, services de collaboration, cybersécurité, cloud, applications internes.
  → Zone d’action forte : le DSI peut ici concevoir une stratégie de substitution, d’hybridation ou d’autonomie.

2. Prioriser selon son pouvoir d’agir

Une approche pragmatique consiste à classer les dépendances selon deux axes :

1. Le niveau de risque (impact sur la continuité, la sécurité, la souveraineté, ou le coût total).
2. Le pouvoir d’action (capacité technique, humaine, financière et organisationnelle à agir).

Le croisement de ces deux axes permet d’obtenir quatre classes de priorisation :

• A. Risque élevé, pouvoir d’agir fort → priorité absolue.
  Exemple : solutions virtualisation, de sauvegarde, de cybersécurité, d’authentification ou de gestion des données dépendantes d’un unique fournisseur. Des alternatives open source (ex. FreeIPA, Keycloak, OPNsense) peuvent être déployées en interne.
  
  Généralement invisible pour les utilisateurs comme pour les décideurs, ce travail peut être réalisé rapidement et efficacement. Les solutions sont nombreuses et, moyennant une gestion de projet correcte, relativement simple à mettre en œuvre. Des prestataires sont disponibles pour déployer des solutions qui ne seront pas dépendantes d’acteurs tiers

• B. Risque élevé, pouvoir d’agir faible → vigilance stratégique.
  Exemple : dépendance aux fournisseurs énergétiques. Ici, la résilience passe par la redondance, les audits de continuité, et le dialogue avec les partenaires publics.
  
  Monitoring, choix de fournisseurs attachés à l’autonomie stratégique et attention portée au bon fonctionnement des services.

• C. Risque faible, pouvoir d’agir fort → opportunité progressive.
  Exemple : migration d’une suite bureautique vers une alternative libre (LibreOffice, OnlyOffice, Nextcloud). Ce type d’action accroît la maîtrise tout en servant de levier culturel interne.
  
  Ici, l’impact sur les utilisateurs est direct, et le changement visible. Chaque déploiement doit être précédé d’une réflexion sur la stratégie de migration, l’accompagnement au changement et l’effort de formation (si nécessaire). Il peut être sage de commencer par une réponse à des besoins non couverts. Un nouvel outil, mis à disposition d’utilisateurs qui n’en disposaient pas auparavant, ne souffrira pas d’une comparaison avec l’existant (et pour cause). Dans un deuxième temps, le remplacement de solutions propriétaires par des solutions libres pourra être envisagé dans un contexte de confiance installée.

• D. Risque faible, pouvoir d’agir faible → faible priorité.
  Exemple : dépendance au silicium ou au réseau mondial. Ces sujets sortent du périmètre d’action d’une DSI.

Sur la base de ce classement, une stratégie intéressante pourrait donc être de porter, dans un premier temps, son attention sur les logiciels d’infrastructure (A), avant de passer aux logiciels communs (C) avec deux phases : commencer par répondre aux besoins non couverts au moyen de solutions libres puis réfléchir, en lien avec les services, au remplacement de certaines solutions logicielles.

La documentation et le monitoring de l’infrastructure et des outils déployés doivent permettre de sécuriser l’ensemble des solutions installées.

3. Domaines d’intervention concrets

Voici quelques domaines où le DSI peut réellement agir :

• Infrastructure et cybersécurité : internaliser les services essentiels (DNS, DHCP, NTP, pare-feu), réduire les dépendances aux solutions SaaS, tester des outils open source éprouvées.

• Collaboration et communication : privilégier des solutions maîtrisées et interopérables (Matrix, Nextcloud, BigBlueButton, Peertube, etc.).

• Systèmes et données : adopter des OS open source, standardiser les bases de données sur des formats ouverts, renforcer la portabilité.

• Cloud et hébergement : mettre en place une stratégie d’hybridation (cloud public + interne + edge), pour combiner flexibilité et maîtrise de l’environnement.

• Gouvernance et culture : adapter sa politique de recrutement, former les équipes, documenter toutes les solutions déployées, intégrer la réversibilité contractuelle dans les appels d’offres, et développer une culture de l’indépendance numérique.

4. Agir progressivement mais durablement

La réduction des dépendances est un processus continu, pas une révolution brusque. Les étapes typiques sont :

1. Mesurer la dépendance (inventaire applicatif et contractuel).
2. Qualifier les risques (juridiques, financiers, opérationnels, réputationnels).
3. Définir une stratégie d’action priorisée.
4. Piloter la transformation par des projets concrets et mesurables.
5. Ancrer la culture d’autonomie numérique auprès des équipes.

La problématique des compétences (et de l’appétence pour le projet) est centrale, comme je l’explique dans cet article. Une mise à niveau de l’équipe (modification des fiches de poste, politique de recrutement, formations éventuelles) est indispensable. S’appuyer sur le turnover naturel de l’équipe pour enrichir l’équipe de profils correspondant au nouveau projet est un facteur majeur de succès.

5. Le DSI, architecte de la résilience

Réduire ses dépendances, c’est gagner en robustesse, agilité et souveraineté. Le rôle du DSI évolue ainsi d’un simple gestionnaire d’infrastructures à un architecte de la résilience numérique. Agir là où c’est possible et fonction de ses capacités, surveiller là où c’est nécessaire, et influencer là où c’est stratégique — telle est la ligne directrice qui peut vous permettre d’avancer vers une autonomie plus grande et une réelle maîtrise de votre système d’information.

Image d’illustration : photo de AbsolutVision sur Unsplash

Attention : cet article concerne un projet en cours à la mairie d’Échirolles. Des options différentes peuvent finalement être choisies… il est même possible qu’il ne voit pas le jour si, dans le cadre de la préparation budgétaire en cours (et en fonction des annonces gouvernementales), le déploiement des interphones n’est pas validé par la collectivité.

Ce travail a fait l’objet d’une présentation dans le cadre du salon « Opensource Experience » 2024. La vidéo est disponible ici.

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.

Mais que se passe-t-il exactement quand on se présente devant un interphone connecté/visiophone et qu’on pousse le bouton permettant d’appeler son interlocuteur ?

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 ?

La réponse est oui.

Déployé au sein d’une infrastructure qui vous appartient, votre parc d’interphones connectés/visiophones permet d’adresser cinq enjeux importants :

1. Cybersécurité
   Que savez-vous du niveau de sécurité associé à votre visiophone ? Le portier repose généralement sur un Linux embarqué, il est connecté à votre réseau, et il se trouve dans la rue où il capte en permanence des images et du son.
   
   Installeriez-vous un PC sous Linux muni d’une webcam, connecté à votre réseau d’entreprise ou de collectivité et accessible depuis la rue 24×7, sans vous soucier un minimum de la sécurisation de votre solution ?
   
2. Respect des données personnelles
   En tant qu’agent d’un service public, vous êtes responsable du bon usage des données de vos administrés. Plusieurs affaires récentes (chez Tesla, par exemple) ont permis de le vérifier : quand il existe, entre le matériel et l’utilisateur, un serveur qui vous ne maîtrisez pas, vous ne pouvez jamais être assuré que vos données ne seront pas consultées par des personnes indélicates.
   
3. Indépendance technique et réactivité
   Rien n’est plus frustrant que de reposer sur un prestataire pour une solution aussi critique que le contrôle d’accès. En cas de problème, une fois écartée votre propre responsabilité technique, vous êtes dans l’impossibilité de faire autre chose que de patienter. Votre capacité à rétablir le service dépend de la vitesse de réaction du prestataire et, d’expérience, vous êtes rarement informé des délais de résolution (et des causes réelles de l’incident).
   
4. Maîtrise des coûts et indépendance économique
   Dans une optique de bonne gestion de l’argent public (et aussi parce que l’État grignote régulièrement les dotations) toutes les collectivités cherchent à minimiser leurs coûts de fonctionnement. Une solution auto-hébergée, parce qu’elle ne nécessite pas de contrat de support (sous réserve que vous ayez quelques compétences en interne), vous permet de ne pas être à la merci d’éventuelles augmentations de tarifs (pensez VMWare et Microsoft).
   
5. Interopérabilité
   La plupart des portiers reposent sur le même protocole, et c’est un protocole standard : SIP. En mettant en place votre propre infrastructure open source, vous pouvez vous permettre de déployer différents modèles d’interphones sans complexifier les usages. Votre solution logicielle reste la même (y compris sur le poste client ou sur le smartphone).

Comme l’indique l’image au-dessus, un interphone est généralement connecté sur un commutateur (switch) de votre réseau. Moyennant une petite configuration sur votre pare-feu, il établit une connexion SIP sur un serveur relais (ou proxy) qui appartient au constructeur (dans « un cloud » vous dit-on souvent).

Ce proxy SIP relaie l’appel à une application propriétaire du constructeur, installé sur un smartphone sous Android ou iOS. Il est également interconnecté avec votre solution de voix-sur-IP interne (Xivo, Alcatel, etc.) pour appeler éventuellement un ou plusieurs postes fixes, et sur votre réseau pour contacter une tablette ou un PC via une solution logicielle pour poste client.

L’idée, évidemment, est d’adresser le rectangle en haut à droite sur l’image ci-dessus, pour que votre solution repose sur une infrastructure que vous contrôlez complètement. Deux logiciels existent, qui vont vous permettre de le réaliser, et ils sont open source !

Une société grenobloise est à l’origine (et maintient) les deux logiciels qui vont nous permettre de mener à bien notre projet : Belledonne communications. Plus connue pour Linphone, son logiciel open source de messagerie unifiée basé (justement) sur SIP, elle est met également à disposition deux logiciels dédiés à l’interphonie.

• Flexisip
  C’est le proxy SIP qui, installé quelque part sur votre réseau, se chargera de relayer les appels des portiers vers les différents terminaux.
  → Toutes les informations sur ce logiciel se trouvent ici.
  → Le code source est accessible sur le Gitlab de Belledonne Communications.

• Linhome (une adaptation de Linphone dédiée à l’interphonie)
  C’est l’application open source, disponible sous Android et iOS (il existe peut-être même une version pour Windows Phone, mais bon…) qui s’ouvrira quand le bouton du portier sera activé et qui permettra de voir l’image de votre interlocuteur, de lui parler, et de déclencher l’ouverture de la porte. Contrairement à Linphone, je ne l’ai pas trouvée sur F-Droid (et donc, sous Android, utilisez Aurora Store)
  → La page de l’application se trouve ici.
  → Le code source peut-être consulté/récupéré sur cette page.

À Échirolles, l’architecture finale devrait ressembler à ça :

Trois précisions importantes sur le projet de la ville d’Échirolles :

• Sur l’état du projet (à la date de rédaction de cet article) :
  Deux interphones connectés de deux marques différentes (Castel et 2N) sont actuellement en cours d’expérimentation dans deux écoles de la ville, et fonctionnent parfaitement bien sur cette architecture comprenant un serveur FlexiSIP et l’application Linhome.

• Sur l’avenir du projet :
  Ce projet est porté par notre direction des services techniques, et la direction de la stratégie numérique n’intervient que dans le choix/le déploiement/la maintenancce de l’infrastructure. Il devrait concerner plusieurs dizaines d’interphones dans nos écoles et dans nos crèches. Le déploiement est prévu pour 2025 sous réserve, la situation politique nationale étant ce qu’elle est, qu’il soit validé lors de la préparation budgétaire en cours.

• Sur les notifications push :
  Il s’agit du mécanisme qui permet de réveiller l’application Linhome, même si elle n’est pas ouverte, quand un appel entrant se produit. Pour des raisons de sécurité, un serveur intermédiaire et des clés spécifiques, fournies par Google ou Apple, sont nécessaires.
  
  Plusieurs options sont envisageables :
  
  → Belledonne communication prévoit de fournir sous peu, moyennant un abonnement (il faut bien payer les développeurs), un serveur de notifications push en mode SaaS.
  
  → Il est possible de compiler (et d’adapter, au passage), sa propre version de Linhome, de faire le travail d’enregistrement auprès de Google et Apple, et de mettre en place ses propres notifications push.
  
  → D’autres systèmes de notification existent et sur lesquels il peut être intéressant de se pencher. C’est le cas de NTFY, par exemple.
  
  Sur ce point, le choix d’Échirolles n’est pas encore fait.

Choisir une distribution Linux n’est pas forcément simple, et dire qu’une distribution est meilleure qu’une autre n’a pas vraiment de sens. Tout dépend du contexte.

Dans la commune ou je travaillais précédemment, nous avions fait le choix de migrer d’abord tous les logiciels d’infrastructure vers des solutions libres (DNS, DHCP, serveur de fichiers, contrôleur de domaine, etc.) avant d’entamer un passage à Linux des postes clients. À Échirolles, nous avons commencé dans un contexte où Microsoft était omniprésent (mais avec une volonté farouche de libérer aussi ces logiciels d’infrastructure).

Le contexte de l’époque (2021)

Nous sommes une collectivité locale. L’immense majorité des nos agents et agentes n’ont pas bénéficié de formation en informatique. Leurs compétences, parfois durement acquises, sont donc limitées. Beaucoup savent exécuter les tâches indispensables à leurs fonctions sans comprendre, et pour cause, les principes sous-jacents.

Dans le service informatique, les gens sont formés à Windows. Certains disposent de certifications et toute l’organisation est basée sur des outils que nous envisageons de remplacer.

Les postes clients tournent tous, à quelques rares exceptions près, avec un système d’exploitation de Microsoft. Au moment où nous commençons à nous interroger, on trouve du Windows 7 (sur les postes les plus anciens), du Windows 10, et quelques Windows 11.

Notre serveur de fichiers, notre DNS, notre DHCP, tournent sur des serveurs Windows. Des stratégies de groupe sont déployées sur les postes clients à partir des habituelles GPO.

L’authentification des postes est assurée par un serveur Active Directory.

Notre messagerie, en revanche, tourne déjà sur un logiciel opensource (BlueMind, à l’époque, SOGo maintenant).

Réflexion préalable

Avant de choisir une distribution, nous nous sommes posés un certain nombre de questions :

• Pourquoi certaines communes, qui avaient fait le choix d’un passage à Linux, ont connu des retours en arrière lors de changements de majorité ?
• Dans certaines communes qui évoluent dans un contexte comparables au nôtre, le service informatique affirme qu’un passage au logiciel libre n’est pas possible. Sur quels critères ? Quels sont les points bloquants selon eux ?
• Existe-t-il une méthodologie de déploiement qui permettrait d’éviter ces écueils ?
• Des collectivités ou des services publics ont, au contraire, réussi leur passage au libre. Quelles méthodes ont été utilisées ?

Vous trouverez des éléments de réponse dans deux articles sur ce blog :

• Échirolles libérée, sur la structuration et les choix organisationnels.
• Résistance au changement et logiciels libres, pour des détails sur la méthode choisie.

Choix de la distribution

L’un des enjeux de la migration est la montée en compétence d’une équipe qui n’est pas formée à Linux. C’est une difficulté, bien sûr, mais c’est aussi une opportunité : parce qu’elle connaît parfaitement l’environnement technique et les habitudes prises par les utilisateurs⋅trices, elle est à même d’identifier les obstacles qui risquent de se présenter. Il est donc indispensable de l’inclure pleinement dans le choix du futur système d’exploitation.

Pendant plusieurs mois, toute l’équipe a été encouragée à installer et tester des distributions variées sur des PC de la collectivité, en ayant à l’esprit que l’ergonomie et l’intégration dans notre système d’information étaient des critères essentiels.

Dans un deuxième temps, chacun s’est penché sur les choix des autres. De mémoire Linux Mint, Elementary OS, Pop OS, Manjaro, Debian, Ubuntu et Zorin OS ont été présentés. Et c’est Zorin OS qui a fait l’unanimité.

Les critères mis en avant par l’équipe :

• la ressemblance avec Windows, avec les mêmes raccourcis-clavier ;
• la possibilité de lui donner en un clic l’apparence d’une version de Windows ou d’une autre (Zorin Appearance) ;
• son intégration dans Active Directory dès l’installation ;
• son design soigné ;
• le fait que la distribution soit basée sur Ubuntu et Gnome et donc l’assurance qu’une documentation fournie et à jour serait disponible en ligne ;
• la distribution évoluant en même temps que les versions Ubuntu, la possibilité de bénéficier de noyaux et de pilotes récents ;
• l’existence de pilotes en français permettant de gérer l’utilisation avancée de nos copieurs et imprimantes (kyodialog, pour les machines Kyocera) ;
• le magasin d’applications, qui était le plus riche parmi les distributions proposées et qui intégrait parfaitement toutes les méthodes d’installation (Flat, Snap et Ubuntu) ;
• l’existence d’une version « lite » (basée sur XFCE, pour les PC les plus anciens) et d’une version « éducation ».

On mesure à quel point le choix s’est porté sur l’intégration dans notre environnement plutôt que sur les mérites techniques relatifs de l’une ou l’autre des distributions envisagées.

Déploiement

Avant d’initier l’installation de notre distribution dans un environnement forcément hybride, un gros travail (quasiment terminé aujourd’hui) a été nécessaire : inventaire (GLPI), prise de main à distance (MeshCentral), déploiement d’images (FOG project)… de nombreuses solutions ont dû être installées, paramétrées, testées, etc.

Pendant ce temps, un bêta-test incluant des personnels choisis (et notamment des décideurs), a permis d’identifier et de résoudre un certain nombre de problèmes et de valider concrètement le choix de notre solution.

En septembre 2024, le déploiement a commencé par un appel à volontariat. Les détails de la stratégie de migration sont disponibles à la fin de cet article.

À la date d’écriture de cet article, l’installation dans les écoles de la ville n’a pas commencé. Pour en comprendre les raisons, vous pouvez vous référer à cet article.

Image d’illustration : Zorin OS 17, de Artyom Zorin, sur Wikimedia Commons.
Licence : GPL.

Ajout du 6 décembre 2024 : suite à la présentation annoncée ci-dessous, un article plus complet a été publié. Il se trouve ici.

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 à 14h salle Alan Cox.

Image d’illustration : Bernard Hermant 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)