Zendesk est-il utile pour une mairie ?

Question

Est-ce que Zendesk peut être utile pour une mairie ?

Réponse

Oui, tout à fait. Une mairie est même un type d'organisation qui peut tirer beaucoup de bénéfices d'un outil comme Zendesk, à condition d'avoir suffisamment de demandes des administrés.

Les principaux usages sont les suivants :

Exemple :

  1. Un habitant signale un lampadaire en panne.
  2. Un ticket est créé automatiquement.
  3. Le service technique est averti.
  4. Le citoyen reçoit un accusé de réception.
  5. Une fois la réparation effectuée, il est informé de la clôture du dossier.

Pour une petite commune, Zendesk peut cependant être surdimensionné en raison de son coût et de sa richesse fonctionnelle.

Quel système équivalent pour une commune de 2 500 habitants ?

Pour une commune d'environ 2 500 habitants, des solutions plus légères sont généralement mieux adaptées.

Quelques exemples :

Les besoins d'une petite commune sont souvent limités à :

Un développement spécifique en PHP peut également répondre à ces besoins avec une interface très simple, quelques tables SQLite (ou des fichiers JSON), un suivi des dossiers et des notifications par courriel.

Pourquoi proposer un développement PHP alors que GLPI est libre ?

Question

Tu dis qu'un développement en PHP est moins coûteux, mais tu cites aussi plusieurs logiciels libres comme GLPI. N'est-ce pas contradictoire ?

Réponse

Ce n'est pas une contradiction, mais deux situations différentes.

Les logiciels comme GLPI, Zammad ou osTicket sont effectivement gratuits dans leur version libre. Cependant, leur utilisation n'est pas totalement gratuite.

Une mairie doit généralement prévoir :

Si ces opérations sont confiées à un prestataire, elles représentent un coût non négligeable.

À l'inverse, un développement spécifique en PHP n'est réellement intéressant que s'il est conçu pour être réutilisé dans de nombreuses communes.

Par exemple :

Le coût du développement est alors amorti sur l'ensemble des installations.

Dans ce cas, le logiciel peut devenir :

En revanche, si une seule mairie commande un logiciel entièrement spécifique, un logiciel libre comme GLPI sera généralement moins cher, car il existe déjà et possède de nombreuses fonctionnalités prêtes à l'emploi.

Conclusion

Il n'y a donc pas de contradiction.

C'est probablement sur ce créneau — les communes de 1 000 à 5 000 habitants — qu'un logiciel spécialisé, beaucoup plus simple que GLPI, pourrait apporter une réelle valeur ajoutée.

Oui, c'est tout à fait possible aujourd'hui. Mieux encore, ce n'est plus de la science-fiction : les grands modèles de langage (LLM) permettent désormais de construire ce type d'application.

L'idée n'est pas de remplacer les agents de la mairie, mais de leur faire gagner énormément de temps.

Principe général

L'habitant pose sa question :

« Je voudrais refaire ma toiture. Ai-je besoin d'une autorisation ? »

ou

« Mon lampadaire est en panne depuis une semaine. »

ou

« Comment inscrire mon enfant à la cantine ? »

Le logiciel :

  1. comprend la question ;
  2. identifie le sujet ;
  3. recherche les informations dans la documentation de la mairie ;
  4. rédige une réponse adaptée ;
  5. si nécessaire, crée automatiquement un dossier destiné au service concerné.

L'agent municipal peut alors :

Architecture

Une architecture simple pourrait être la suivante :

Habitant
    │
    ▼
Formulaire Web
    │
    ▼
PHP
    │
    ├── Classification de la demande
    ├── Recherche documentaire
    ├── IA
    ├── Gestion des tickets
    └── Réponse

Les connaissances

L'IA n'invente rien.

Elle s'appuie uniquement sur :

Toutes ces informations peuvent être converties en Markdown, PDF ou texte.

Une base documentaire

Par exemple :

documents/

urbanisme.md
cantine.md
état-civil.md
associations.md
déchets.md
élections.md
eau.md
...

Chaque document contient les informations officielles.

Fonctionnement

L'utilisateur demande :

Je veux construire un abri de jardin de 18 m².

Le logiciel :

Elle ne répond jamais à partir de ses connaissances générales mais uniquement à partir des documents municipaux.

Pourquoi PHP suffit

PHP joue uniquement le rôle d'orchestrateur.

Il :

Le travail "intelligent" est réalisé par le modèle de langage.

Peut-on se passer d'OpenAI ?

Oui.

On peut utiliser un modèle local comme :

Le fonctionnement reste identique.

Une idée encore plus intéressante

La plupart des communes de moins de 5 000 habitants possèdent très peu de documents.

Souvent :

Toute cette documentation peut être indexée.

Le logiciel devient alors un véritable "secrétaire numérique" de la mairie.

Ce qui ferait la différence

À mon avis, l'innovation ne résiderait pas dans l'IA elle-même.

Elle résiderait dans un logiciel extrêmement simple :

L'objectif serait qu'une secrétaire de mairie puisse l'utiliser sans formation particulière.

Pour les petites communes, un tel logiciel serait probablement plus adapté qu'un outil généraliste comme GLPI, car il serait conçu spécifiquement pour leur organisation et leurs besoins quotidiens.

Coût d'utilisation des modèles locaux

Lorsque je parle de Mistral, Llama, Gemma ou Qwen, il faut distinguer deux situations.

1. Utilisation en local

Le modèle est installé sur votre propre ordinateur ou sur le serveur de la mairie.

Coût logiciel

Le coût des licences est donc généralement 0 €.

Le seul coût est le matériel.

Matériel

Pour une petite mairie (2 500 habitants), un simple PC peut suffire.

Exemple :

Prix : 800 à 1 500 €

Pour un meilleur confort :

Prix total :

1 500 à 3 000 €

Une fois acheté, il n'y a pratiquement plus de coût d'utilisation.

Le modèle peut répondre à des milliers de questions par jour.

2. Utilisation via Internet (API)

Le modèle tourne sur les serveurs d'un fournisseur.

On paie uniquement ce que l'on consomme.

Par exemple :

Le coût est calculé en fonction du nombre de tokens (morceaux de texte).

Pour une petite mairie recevant :

le coût mensuel est généralement de l'ordre de :

Autrement dit, le coût est souvent inférieur à celui d'un abonnement téléphonique.

3. Quel est le plus économique ?

Pour une mairie de 2 500 habitants :

4. Mon choix

Si je devais concevoir un logiciel destiné à des centaines de petites communes, je proposerais une architecture hybride.

Par exemple :

Ainsi, la même application pourrait être installée aussi bien dans une petite commune rurale que dans une ville plus importante, sans changer son fonctionnement.

Comment cela se passerait concrètement ?

Prenons l'exemple d'une mairie de 2 500 habitants.

L'objectif est de construire un assistant municipal intelligent.

1. Le citoyen pose une question

Sur le site de la mairie, il écrit simplement :

Bonjour, je voudrais refaire ma toiture.

ou

Mon voisin fait du bruit tous les soirs.

ou

À quelle heure ouvre la mairie ?

Il clique sur Envoyer.

2. Le serveur PHP reçoit la question

Le script PHP enregistre la demande.

Par exemple :

Question :

Je voudrais refaire ma toiture.

3. PHP recherche les documents utiles

Il possède une base documentaire.

Par exemple :

documents/

urbanisme.md
cantine.md
associations.md
élections.md
plu.md
déchets.md
horaires.md
...

Le logiciel recherche automatiquement les documents qui parlent de :

Il ne sélectionne que les documents utiles.

4. Construction du contexte

PHP fabrique alors un texte ressemblant à ceci :

Tu es l'assistant de la mairie.

Tu réponds uniquement à partir des documents suivants.

=====

Document urbanisme.md

...

=====

Document PLU.md

...

=====

Question du citoyen

Je voudrais refaire ma toiture.

C'est ce texte qui sera envoyé au modèle d'IA.

5. Le modèle répond

Le modèle lit uniquement ces documents.

Il répond par exemple :

Si votre projet consiste uniquement à remplacer les tuiles à l'identique, aucune autorisation n'est généralement nécessaire.

En revanche, si vous modifiez l'aspect extérieur de la toiture, une déclaration préalable peut être obligatoire.

Vous pouvez retirer le formulaire CERFA à l'accueil de la mairie ou le télécharger sur le site.

Cette réponse est renvoyée au PHP.

6. PHP affiche la réponse

L'habitant voit immédiatement la réponse.

Il peut ensuite cliquer sur :

Où intervient réellement l'IA ?

Le modèle n'a jamais accès à toute la base documentaire.

Il reçoit uniquement :

Quelques secondes plus tard, il oublie tout.

Il ne conserve aucune mémoire de la commune.

Si l'on utilise un modèle local

À la place d'OpenAI, on installe par exemple Qwen ou Mistral sur un ordinateur de la mairie.

Le déroulement est exactement le même.

La seule différence est que, lorsque PHP arrive à l'étape 4, il envoie la requête à un programme installé sur le réseau local.

Navigateur

      │

      ▼

PHP

      │

      ▼

Serveur IA de la mairie

      │

      ▼

Réponse

      │

      ▼

Navigateur

Aucune donnée ne quitte la mairie.

Ce qui est intéressant

Le logiciel n'est pas lié à une IA particulière.

Il peut fonctionner avec :

Le code PHP reste pratiquement identique.

Il suffit de changer la fonction qui envoie la question au modèle.

Ainsi, si dans deux ans un nouveau modèle est deux fois plus performant et dix fois moins cher, il suffira de modifier cette seule fonction sans réécrire tout le logiciel.

En réalité, l'IA n'indexe pas directement les pages. C'est une idée très répandue, mais ce n'est pas ainsi que fonctionnent les systèmes modernes.

Le schéma est généralement le suivant.

1. Découpage des documents

Chaque document est découpé en petits morceaux (appelés chunks).

Par exemple :

urbanisme.md

----------------------
Chunk 1
Présentation du service

----------------------
Chunk 2
Déclaration préalable

----------------------
Chunk 3
Permis de construire

----------------------
Chunk 4
Abri de jardin

----------------------
Chunk 5
Piscine

Chaque morceau contient entre 300 et 1 000 mots.

2. Calcul d'un vecteur (Embedding)

Chaque morceau est envoyé dans un petit modèle spécialisé.

Ce modèle ne produit pas une réponse.

Il produit un vecteur de nombres.

Par exemple :

Chunk 4

↓

[0.241,
-0.773,
0.015,
...
0.918]

Il peut contenir :

Ce vecteur représente la signification du texte.

Deux textes ayant le même sens auront des vecteurs très proches, même s'ils utilisent des mots différents.

3. Stockage

Tous ces vecteurs sont enregistrés.

Vecteur 1 → Chunk 1

Vecteur 2 → Chunk 2

Vecteur 3 → Chunk 3

...

On parle alors de base vectorielle.

4. Une question arrive

Le citoyen écrit :

Puis-je construire un cabanon de 15 m² ?

La question est elle aussi transformée en vecteur.

Question

↓

Embedding

↓

[0.238,
-0.770,
0.011,
...
0.921]

5. Recherche des voisins les plus proches

Le logiciel compare ce vecteur avec tous les autres.

Il calcule une distance.

Les plus utilisées sont :

Les morceaux les plus proches sont sélectionnés.

Par exemple :

Question

↓

Chunk 4 : 99 %

Chunk 3 : 94 %

Chunk 7 : 71 %

Chunk 15 : 22 %

Le logiciel garde uniquement les meilleurs résultats.

6. Envoi au LLM

Seuls ces morceaux sont envoyés au modèle.

Le modèle ne lit donc jamais les 500 documents.

Il ne lit que :

Question

+

Chunk 4

+

Chunk 3

+

Chunk 7

Il peut alors rédiger une réponse.

Les algorithmes utilisés

En pratique, plusieurs familles d'algorithmes interviennent.

Embedding

Ils transforment le texte en vecteurs.

Exemples :

Recherche vectorielle

Ils retrouvent rapidement les vecteurs les plus proches.

Les plus connus sont :

Ces algorithmes sont optimisés pour rechercher des voisins dans des espaces contenant parfois des millions de vecteurs.

Base vectorielle

Elle stocke les vecteurs.

Exemples :

Dans ton cas

Pour une mairie de 2 500 habitants, tu n'as probablement que :

C'est extrêmement petit pour les outils actuels.

Tu pourrais même te passer d'une base vectorielle spécialisée.

Une solution très simple serait :

  1. convertir tous les documents en chunks ;
  2. calculer leurs embeddings une seule fois ;
  3. enregistrer les vecteurs dans une base SQLite ;
  4. lors d'une question, calculer l'embedding de la question ;
  5. comparer ce vecteur à tous les autres.

Avec seulement quelques milliers de vecteurs, cette comparaison prend généralement moins d'une seconde sur un PC ordinaire.

Autrement dit, il est tout à fait envisageable de construire un assistant municipal intelligent en PHP, avec SQLite pour stocker les documents et les embeddings, sans avoir besoin d'une infrastructure complexe.

Je pense qu'il faut distinguer deux objectifs.

  1. Construire rapidement une maquette du nouveau site.
  2. Constituer une base documentaire qui servira ensuite à l'IA.

Je te proposerais donc un seul outil qui réalise les deux.

Étape 1 : Exploration du site

Le programme explore tout le site à partir de l'URL d'accueil.

Par exemple :

php site2md.php https://www.mairie.fr

Il récupère toutes les URL.

Étape 2 : Filtrage

Il conserve uniquement :

Il ignore :

Étape 3 : Téléchargement

Il télécharge uniquement ces documents.

Étape 4 : Extraction

Pour chaque page HTML :

Pour chaque PDF :

Étape 5 : Conversion

Tous les documents deviennent du Markdown.

Par exemple :

sources/

urbanisme.md
cantine.md
ecoles.md
budget2025.md
compte_rendu_2025_04_12.md
...

Étape 6 : Création d'un index

Le programme génère automatiquement un fichier.

index.json

contenant :

Pourquoi je choisirais PHP

Parce que tu maîtrises déjà :

Tu n'as donc pas besoin d'ajouter un nouvel environnement.

PHP peut très bien :

On peut utiliser Bash uniquement pour lancer le programme.

Je n'utiliserais wget que pour une seule chose

Explorer le site.

Par exemple :

wget \
  --spider \
  --recursive \
  --no-parent \
  --quiet \
  https://www.mairie.fr

Il est très performant pour découvrir toutes les URL.

Ensuite, je laisserais PHP faire tout le reste.

Le résultat final

À la fin, tu disposerais de quatre répertoires.

/projet

    site2md.php

    /sources
        *.md

    /pdf
        *.pdf

    /cache

    index.json

Tu pourrais alors :

Pourquoi je te conseille cette architecture

Elle est progressive.

  1. Tu obtiens rapidement une copie exploitable du site.
  2. Tu reconstruis le nouveau site en Markdown.
  3. Plus tard, tu ajoutes l'assistant intelligent en réutilisant exactement les mêmes fichiers Markdown.

Ainsi, le travail réalisé aujourd'hui servira directement à la future IA, sans avoir à recommencer l'extraction des données.

Conception du collecteur de site municipal

Objectif

Créer un outil PHP permettant de récupérer l'ensemble des ressources utiles d'un site Internet de mairie afin de préparer une refonte complète.

Le principe fondamental est :

La collecte conserve les sources originales. Aucune transformation n'est réalisée pendant cette phase.

Le collecteur sert uniquement à réaliser une copie documentaire fidèle du site existant.

Principe général

Entrée :

URL du site municipal

Exemple :

https://www.mairie-exemple.fr

Sortie :

collecte_mairie/

contenant toutes les ressources récupérées.

Architecture générale

                Site de la mairie

                       |
                       ▼

              Explorateur de liens

                       |
                       ▼

              Filtrage des ressources

                       |
                       ▼

              Téléchargement

                       |
                       ▼

              Classement automatique

                       |
                       ▼

              Rapport de collecte

1. Exploration du site

Le programme commence par l'URL principale.

Exemple :

https://www.mairie-exemple.fr

Il analyse les liens présents dans :

Il ne quitte jamais le domaine de la mairie.

Exemple :

Autorisé :

https://www.mairie-exemple.fr/contact

Refusé :

https://facebook.com/mairie

2. Sélection des ressources

Ressources conservées

Pages

.html
.htm

Stockées dans :

html/

Documents administratifs

.pdf
.doc
.docx
.odt

Stockés dans :

documents/
pdf/

Tableurs

.xls
.xlsx
.csv

Stockés dans :

tableurs/

Ressources techniques

Conservées car elles permettent de comprendre l'ancien site.

.css
.js

Stockage :

assets/css/
assets/js/

Icônes et éléments graphiques légers

Conservés :

.svg
.ico
petits .png

Stockage :

assets/icons/

3. Ressources ignorées

Pour éviter de récupérer des centaines de mégaoctets inutiles :

.mp4
.mp3
.wav
.zip
.rar

Les grandes images décoratives sont également ignorées :

.jpg
.jpeg

sauf si elles sont identifiées comme logo ou icône.

4. Organisation des fichiers

Le résultat final :

collecte_mairie/

├── html/
│
├── pdf/
│
├── documents/
│
├── tableurs/
│
├── assets/
│   ├── css/
│   ├── js/
│   └── icons/
│
└── meta/
    ├── urls.csv
    ├── fichiers.csv
    └── rapport.txt

5. Gestion des doublons

Chaque fichier récupéré reçoit une empreinte :

SHA256

Exemple :

contact.html

SHA256 :
a82f94c8e5...

Si le même fichier apparaît plusieurs fois :

6. Conservation des informations

Pour chaque ressource :

Nom du fichier

URL d'origine

Date de récupération

Type de fichier

Taille

Empreinte SHA256

Exemple :

fichier;url;type;taille;hash

contact.html;
https://mairie.fr/contact;
html;
15200;
8ab43d...

7. Reprise après interruption

Le programme doit pouvoir être arrêté puis relancé.

Exemple :

Premier lancement :

Pages analysées : 300
PDF récupérés : 40

Arrêt.

Deuxième lancement :

Pages déjà récupérées : ignorées
Nouvelles pages : téléchargées

Aucun travail inutile n'est refait.

8. Technologies utilisées

L'environnement reste volontairement simple.

PHP

Pour :

Bibliothèques natives :

cURL

DOMDocument

fichiers JSON ou CSV

Bash / Termux

Pour :

9. Commande unique

L'utilisateur lance :

php mairie2collect.php https://www.mairie-exemple.fr

Le programme affiche :

Début de collecte

HTML        : 245 fichiers
PDF         : 67 fichiers
DOC/DOCX    : 14 fichiers
CSS         : 9 fichiers
JS          : 6 fichiers
Icônes      : 18 fichiers

Taille totale :
320 Mo

Collecte terminée.

10. Ce qui n'est volontairement pas fait

Le collecteur ne :

Ces opérations appartiennent à une deuxième étape.

Résultat attendu

À la fin de cette phase, on possède une archive complète et fiable du site municipal.

Cette archive pourra ensuite servir à :

La collecte devient donc une étape indépendante, stable et réutilisable.

mairie2collect.php — Collecteur de site municipal amélioré

Objectif

Ce programme réalise uniquement la collecte des sources.

Il ne transforme rien.

Il conserve :

Il génère :

Utilisation

Analyse sans téléchargement :

php mairie2collect.php https://www.mairie.fr --dry-run

Collecte complète :

php mairie2collect.php https://www.mairie.fr

Limiter la profondeur :

php mairie2collect.php https://www.mairie.fr --depth=5

Structure générée

collecte_mairie/

├── html/
├── pdf/
├── documents/
├── tableurs/
├── assets/
│   ├── css/
│   ├── js/
│   └── icons/
│
└── meta/
    ├── urls.csv
    ├── fichiers.csv
    └── rapport.txt

Code PHP

Je vais fournir le code complet dans le message suivant afin de conserver un bloc Markdown unique et éviter une coupure du programme.

Le programme intégrera directement :

Analyse approfondie du code source de la page d'accueil d'Estagel

Les informations supplémentaires que tu fournis permettent d'aller beaucoup plus loin.

On peut maintenant identifier beaucoup plus précisément l'architecture technique utilisée par Réseau des Communes / NEOPSE.

Ma première conclusion :

Ce n'est pas un simple site HTML. C'est une véritable plateforme CMS propriétaire avec génération dynamique de pages, système de widgets, personnalisation par commune et infrastructure mutualisée.

1) Confirmation : plateforme NEOPSE

Le premier indice très fort est ici :

var u="//matomo-client.neopse.com/";

et :

https://static.neopse.com/

On retrouve plusieurs domaines appartenant à NEOPSE :

static.neopse.com
matomo.neopse.com
matomo-client.neopse.com

Cela confirme que :

Architecture probable :

Visiteur
   |
   |
estagel.fr
   |
   |
Serveurs Réseau des Communes / NEOPSE
   |
   +-- HTML
   +-- CSS
   +-- JS
   +-- Images
   +-- Matomo

2) Ce n'est pas un CMS classique

On peut quasiment exclure :

Pourquoi ?

Parce que le code contient des éléments propres à leur plateforme :

xmlns:ff4j
xmlns:esi

notamment :

xmlns:esi="http://www.edge-delivery.org/esi/1.0"

ESI signifie :

Edge Side Includes

C'est une technologie utilisée pour assembler des pages côté serveur ou CDN.

Cela indique une architecture plus industrielle.

3) Utilisation probable d'un framework professionnel

L'indice :

xmlns:ff4j="http://www.w3.org/1999/xhtml"

FF4J correspond probablement à :

Feature Flipping for Java

C'est une bibliothèque Java permettant d'activer/désactiver des fonctionnalités.

Cela laisse penser que le backend pourrait être développé en Java.

Architecture possible :

             Application Java
                   |
                   |
        ------------------------
        |                      |
 Base de données          Générateur HTML
        |
        |
 Gestion communes
 Gestion menus
 Gestion contenus
 Gestion utilisateurs

Je précise : ce n'est pas une preuve absolue, mais c'est un indice très fort.

4) Le système de personnalisation est très poussé

Cette partie est intéressante :

#w_headline
#w_44vmgbr2l
#w_dm455tmfy
#w_ez8ne90kx
#w_w5a7v1zv1
#w_wmxocox59
#w_y652xyj73

Ces identifiants sont générés automatiquement.

Cela ressemble à un système de blocs :

Page accueil

+----------------+
| Bloc actualité |
| id=w_headline  |
+----------------+

+----------------+
| Agenda         |
| id=w_xxxxx     |
+----------------+

+----------------+
| Liens utiles   |
| id=w_xxxxx     |
+----------------+

Chaque commune peut donc probablement composer sa page avec des modules.

5) Le gros défaut : génération excessive de CSS

La partie :

<style class="notranslate" title="customCss">

contient énormément de CSS spécifique.

Exemple :

#w_w5a7v1zv1 .bg {
background-color: rgba(224,122,127,0.7);
}

Cela signifie :

Chaque bloc possède son propre style.

C'est pratique pour un administrateur non informaticien :

"je change la couleur du bloc"

Mais techniquement :

6) Les polices

On voit :

Montserrat
Inter
Jost
Lato
Lora
Merriweather
Nunito
Open Sans
Outfit
Roboto
Roboto Condensed
Roboto Slab

Ils chargent énormément de polices Google.

Pour un site simple, c'est excessif.

Cela permet probablement de proposer dans l'administration :

"choisir la police du site".

Mais le coût :

7) Les bibliothèques JavaScript

On confirme :

Bootstrap

bootstrap.min.js
jquery-3.2.1.min.js
popper.min.js

Donc Bootstrap 4 environ.

Carrousels

Trois systèmes :

owlcarousel
slick
splide

C'est surprenant.

Un développement plus propre choisirait un seul composant.

Cela ressemble à une plateforme qui a grandi par ajout successif de fonctionnalités.

8) Le menu confirme le fonctionnement interne

Exemple :

/fr/rb/2338780/page-d-accueil

On retrouve :

rb

probablement rubrique.

Puis :

2338780

identifiant interne.

Puis :

page-d-accueil

nom lisible.

Donc :

TYPE / ID / SLUG

Architecture classique d'un CMS métier.

9) Comparaison avec un CMS moderne simple

Leur approche

Base de données
       |
       |
CMS propriétaire
       |
       |
HTML généré
       |
       |
Navigateur

Avantages :

Inconvénients :

Une approche comme celle que tu développes

Markdown
    |
    |
Parser
    |
    |
HTML
    |
    |
Navigateur

Avantages :

Inconvénients :

10) Mon jugement technique après ces nouvelles informations

Je modifie légèrement mon analyse précédente.

Ce n'est pas une architecture "ancienne bricolée".

C'est une architecture professionnelle.

Elle semble conçue pour :

Par contre :

elle est lourde.

Pour une seule commune comme Estagel, cette puissance est probablement largement supérieure au besoin réel.

Les points qui me gênent techniquement

1. Dépendance forte à NEOPSE

Les ressources :

static.neopse.com
matomo.neopse.com

montrent une dépendance infrastructurelle.

2. Beaucoup de JavaScript et CSS

La page d'accueil de 1700 lignes HTML n'est pas choquante pour une plateforme.

Mais elle indique un système très riche.

3. Personnalisation par accumulation

Les nombreux blocs :

#w_xxxxxxxxx

font penser à un constructeur de pages.

C'est efficace, mais rarement élégant.

Conclusion finale

Avec ce code source, je dirais :

Réseau des Communes utilise une vraie plateforme CMS propriétaire professionnelle développée par NEOPSE, probablement basée sur une architecture Java, avec génération dynamique de sites municipaux.

Ce n'est pas un mauvais produit.

Mais c'est un choix opposé à une philosophie de sobriété :

Le vrai sujet n'est donc pas la qualité technique.

Le vrai sujet est :

la commune accepte-t-elle de confier une partie de son autonomie numérique à un éditeur spécialisé ?

Le WHOIS montre qu'ils ont fait un choix correct en laissant le domaine à la commune. Le prochain point à examiner serait le contrat : c'est lui qui dira si la réversibilité des contenus est réellement garantie.