Analyse complète du site de la Commune d'Estagel réalisé par Réseau des Communes / NEOPSE

Objet de l'analyse

Cette analyse porte sur le site internet de la Commune d'Estagel, réalisé avec la plateforme de Réseau des Communes, dont les mentions légales indiquent :

Réseau des Communes
SAS au capital de 47 205 euros
RCS Paris 493 784 672
Code APE : 6311Z
Siège social :
132 rue du Faubourg Saint-Denis
75010 Paris

Les mentions légales indiquent également que la propriété intellectuelle de la plateforme appartient à :

NEOPSE

L'analyse a été réalisée à partir :

1) Propriété du nom de domaine

Résultat du WHOIS

Le domaine :

estagel.fr

est enregistré auprès de :

GANDI

Le titulaire officiel est :

Commune d'Estagel
6 avenue Docteur Torreilles
66310 Estagel

Conclusion

C'est un point très positif.

Le prestataire :

Réseau des Communes

n'est pas propriétaire du nom de domaine.

Il intervient uniquement comme :

La commune conserve donc son identité numérique.

2) Évaluation de la pratique concernant le domaine

Une mauvaise pratique aurait été :

Prestataire
      |
      |
 propriétaire du domaine

Ce qui aurait créé une dépendance forte.

La situation observée est :

Commune d'Estagel
       |
       |
 propriétaire du domaine
       |
       |
Réseau des Communes
       |
       |
 gestion technique

Cette organisation est saine.

La commune pourra conserver :

même en cas de changement de prestataire.

3) Nature du logiciel utilisé

L'analyse du code source montre qu'il ne s'agit pas d'un CMS classique.

Il ne s'agit probablement pas de :

La plateforme semble être un CMS propriétaire développé par :

NEOPSE

pour Réseau des Communes.

4) Indices techniques identifiés

Domaines NEOPSE utilisés

Le code contient :

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

Cela montre une infrastructure centralisée.

Les ressources peuvent être servies depuis l'écosystème NEOPSE :

Technologies détectées

Bootstrap

Présence de :

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

Le site utilise probablement Bootstrap 4.

Librairies graphiques

Présence de :

owlcarousel
slick
splide

pour les carrousels et animations.

Cartographie

Présence de :

leaflet

Bibliothèque cartographique libre.

Graphiques

Présence de :

Chart.js

pour les graphiques.

Gestion des cookies

Présence de :

tarteaucitron.js

Solution très utilisée en France pour la conformité RGPD.

5) Architecture probable du système

La structure observée correspond probablement à :

                 Base de données
                       |
                       |
              Application NEOPSE
                       |
       --------------------------------
       |                              |
 Gestion des contenus          Gestion graphique
       |                              |
 Articles                       Templates
 Menus                          Couleurs
 Documents                      Widgets
 Photos                         Blocs
       |
       |
 Génération des pages
       |
       |
        Site de la commune

6) Organisation des fichiers

L'arborescence contient :

assets
documents
html
meta
pdf
tableurs

La partie :

html/fr/

contient directement des fichiers HTML.

Exemples :

mentions-legales-1757.html
agenda-1652.html
mot-du-maire-101.html

Cela indique probablement une génération de pages HTML à partir d'une base de données.

7) Système d'identification interne

Les URLs utilisent des identifiants :

Exemple :

/fr/nw/2543803/vie-du-village

Structure :

TYPE / IDENTIFIANT / NOM

Exemples :

rb

probablement rubrique.

nw

probablement news / actualités.

ev

événements.

tb

conseil municipal.

ed

éditos.

Ces identifiants sont pratiques pour la plateforme mais peu lisibles pour un humain.

8) Système de widgets

Le code montre un système de blocs :

Exemples :

#w_headline
#w_44vmgbr2l
#w_dm455tmfy
#w_w5a7v1zv1

Chaque élément de la page possède un identifiant unique.

Cela correspond probablement à un constructeur de pages :

Accueil

+----------------+
| Actualités     |
+----------------+

+----------------+
| Agenda         |
+----------------+

+----------------+
| Informations   |
+----------------+

Chaque commune peut composer son site avec différents modules.

9) Personnalisation graphique

Le site génère un CSS spécifique :

<style title="customCss">

Ce CSS contient :

Exemple :

#w_w5a7v1zv1 .bg

Chaque widget peut avoir sa propre apparence.

Avantage :

Inconvénient :

10) Gestion du responsive

La plateforme utilise JavaScript pour adapter certains éléments.

Exemple :

window.matchMedia("(max-width:979px)")

Elle modifie dynamiquement les couleurs et comportements sur tablette/mobile.

Ce fonctionnement est plus complexe qu'une simple utilisation de :

@media

11) Gestion des statistiques

Deux outils sont présents.

Matomo

matomo.neopse.com

Utilisé pour :

Instana

Présence de :

eum.instana.io

Utilisé pour :

Cela montre une infrastructure professionnelle.

12) Gestion des formulaires

Les formulaires utilisent :

Exemple :

hcaptcha.com

Objectif :

13) Points positifs de la solution

Au niveau technique

Au niveau contractuel

Point important :

14) Points de vigilance

Dépendance au fournisseur

La commune dépend fortement de :

NEOPSE / Réseau des Communes

pour :

Réversibilité

Il faut vérifier :

Complexité technique

La solution est très riche mais aussi lourde :

Nombreux composants :

CMS
+
widgets
+
templates
+
JavaScript
+
bibliothèques graphiques
+
services externes

Pour une petite commune, cette puissance peut être supérieure au besoin réel.

15) Comparaison avec une approche légère

Une solution légère pourrait être :

Pages Markdown
       |
       |
Conversion HTML
       |
       |
Site web

Avantages :

La solution NEOPSE est différente :

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

Avantages :

Inconvénients :

16) Avis global

Sur le sérieux de l'entreprise

Les éléments observés indiquent une entreprise techniquement sérieuse :

Il ne s'agit pas d'un simple prestataire qui fabrique quelques sites.

Sur l'architecture

L'architecture est :

Mais elle est :

Conclusion finale

Réseau des Communes / NEOPSE semble être une solution professionnelle destinée aux collectivités qui souhaitent un site clé en main.

Le choix technique est cohérent pour gérer de nombreux sites municipaux.

Le principal sujet de réflexion n'est pas la qualité technique de la plateforme.

Le véritable enjeu est l'autonomie de la commune :

L'analyse du code montre donc :

une plateforme sérieuse et professionnelle, mais avec une forte dépendance au fournisseur.

Analyse complémentaire du site de la commune d'Estagel (Réseau des Communes / NEOPSE)

Tu soulèves un point qui n'apparaît pas dans l'analyse technique : la qualité visuelle et l'expérience utilisateur.

À partir du code HTML/CSS fourni, on peut effectivement comprendre pourquoi le rendu peut donner une impression de « patchwork ».

1. Origine probable du problème : un générateur de sites avec personnalisation par blocs

Le site semble être produit par une plateforme propriétaire de type CMS multi-sites.

Indices :

Cela ressemble davantage à un système où l'utilisateur assemble des modules préfabriqués qu'à un véritable travail de direction artistique.

2. Le problème principal : absence de charte graphique globale

Dans le CSS fourni, on voit :

Chaque bloc semble pouvoir avoir :

Le résultat peut facilement devenir incohérent.

Un site institutionnel moderne devrait plutôt avoir :

Ici, on a l'impression inverse : chaque module semble avoir été décoré séparément.

3. Les polices

Le site charge une quantité importante de polices Google :

Charger autant de possibilités n'est pas forcément un problème techniquement, mais cela indique probablement que la plateforme permet de choisir beaucoup de styles.

Le danger est qu'une mauvaise configuration donne :

Cela donne rapidement une impression amateur.

4. Comparaison avec une approche plus professionnelle

Un site municipal bien conçu aurait généralement :

Structure :
    header
    navigation claire
    page d'accueil aérée
    blocs homogènes
    footer

Design :
    2 ou 3 couleurs maximum
    même style de boutons partout
    mêmes espacements
    même typographie
    images cohérentes

Alors que ce site semble fonctionner ainsi :

Bloc A :
    couleur + texture + style

Bloc B :
    autre couleur + autre texture + autre style

Bloc C :
    autre configuration

Ce qui explique l'effet de juxtaposition.

5. Concernant le sérieux de l'entreprise

Les éléments techniques montrent une entreprise réelle :

Donc ce n'est pas une société fantôme.

En revanche, le fait qu'une entreprise soit sérieuse juridiquement ne signifie pas forcément que :

6. Mon avis sur ce site précis

À partir des éléments fournis :

Points positifs

Points négatifs

Mon impression générale :

Réseau des Communes semble être un prestataire techniquement établi, mais la solution paraît davantage conçue comme un générateur industriel de sites municipaux que comme une création web sur mesure avec une vraie réflexion graphique.

Le problème que tu constates (site laid, manque de cohérence, effet patchwork) est cohérent avec ce type d'architecture.

Analyse de la structure technique du site Réseau des Communes / NEOPSE

Ton ressenti d'un point de vue programmeur est compréhensible à la lecture de l'arborescence.

Il faut cependant distinguer deux choses :

Une architecture peut être complexe parce qu'elle répond à des contraintes industrielles, sans forcément être élégante.

1. Pourquoi cette structure donne une impression d'usine à gaz

Plusieurs éléments attirent immédiatement l'attention.

A. Une arborescence très profonde

Exemple :

html/fr/nw/2543803/2638599/ecole-de-rugby-estagel-xiii-vallee-de-lagly.html

Pour une page d'information simple, on a :

C'est une approche typique d'un CMS qui stocke ses identifiants techniques dans les URL.

Pour un développeur qui privilégie :

cela paraît effectivement lourd.

Une approche plus moderne aurait souvent :

/actualites/ecole-de-rugby-estagel-xiii

avec les identifiants conservés en interne dans une base.

B. Mélange de fichiers techniques et de contenus générés

On trouve :

assets/
html/
documents/
meta/
pdf/
tableurs/

Cela ressemble à une génération statique de pages à partir d'une base applicative.

Ce n'est pas forcément mauvais, mais cela montre une architecture pensée autour du moteur interne plutôt qu'autour de la simplicité du site.

C. Beaucoup de bibliothèques JavaScript chargées

Le site utilise notamment :

Cela représente beaucoup de dépendances.

Certaines fonctionnalités pourraient probablement être réalisées aujourd'hui avec beaucoup moins de code.

Par exemple :

Cela donne une impression d'empilement historique.

D. Beaucoup de personnalisation injectée par CSS

La partie :

<style title="customCss">
...
</style>

contient énormément de règles générées.

On voit une logique :

"chaque bloc peut être personnalisé".

C'est pratique pour vendre un CMS à beaucoup de collectivités :

Mais techniquement, cela peut produire :

2. Est-ce une mauvaise architecture ?

Pas forcément.

Il faut reconnaître une contrainte importante :

Cette entreprise ne fabrique probablement pas un site unique.

Elle doit gérer :

Une architecture industrielle peut donc avoir du sens.

Le problème est plutôt le compromis choisi.

3. Le sentiment de "programmateurs laborieux"

Ce que tu ressens vient probablement de plusieurs choix techniques :

On retrouve une philosophie :

"prévoir tous les cas possibles"

plutôt que :

"faire un système simple qui couvre 90 % des besoins".

C'est une approche fréquente dans les gros CMS professionnels.

4. Comparaison avec une approche plus légère

Une solution plus simple pourrait être :

/pages
    accueil.md
    mairie.md
    associations.md
    actualites.md

/assets
    style.css
    app.js

/uploads
    images
    documents

Avec :

Cela pourrait produire un site :

5. Mon avis technique

À partir des éléments visibles :

Je ne dirais pas que c'est "mal programmé".

Je dirais plutôt :

c'est une architecture de plateforme administrative construite par accumulation de fonctionnalités, avec une forte orientation CMS, au détriment probable de la simplicité et de l'élégance.

Ton impression d'"usine à gaz" est donc compréhensible, surtout avec une culture de programmation où l'on recherche :

Le site semble avoir été conçu pour satisfaire beaucoup de besoins différents, mais pas forcément pour atteindre une sobriété technique ou esthétique.

Analyse des avis concernant Réseau des Communes (NEOPSE)

Les avis que tu fournis apportent un élément nouveau : ils ne concernent plus seulement la technique du site, mais la relation client et le fonctionnement de l'entreprise.

Il faut toutefois rester prudent : les avis GoWork sont peu nombreux et ne constituent pas une enquête représentative. Ils peuvent contenir des avis authentiques, mais aussi des avis isolés ou non vérifiés.

Cela étant dit, certains points sont intéressants à analyser.

1. Nombre et nature des avis

D'après les informations fournies :

Ce volume est faible.

On ne peut donc pas conclure :

"Cette entreprise est mauvaise"

uniquement avec ces avis.

En revanche, on peut dire :

"Les rares personnes qui ont pris le temps de laisser un avis expriment majoritairement une insatisfaction importante."

2. Avis concernant le support et la dépendance au prestataire

L'avis le plus intéressant est celui-ci :

"Changement d'équipe à la Mairie, impossible de leur faire changer les administrateurs, le site ne peut pas être mis à jour, très mauvaise image pour les nouveaux élus et ils osent envoyer la facture alors que le site est inutilisé et inutilisable depuis 3 mois."

Ce point est particulièrement important pour une mairie.

Une collectivité doit conserver une certaine autonomie.

Un changement d'équipe municipale est un événement normal :

Si la modification des administrateurs dépend fortement du prestataire et bloque l'utilisation du site pendant plusieurs mois, c'est un problème sérieux.

Cela rejoint une interrogation que tu avais déjà soulevée :

La dépendance au fournisseur

La question essentielle n'est pas seulement :

"Le site fonctionne-t-il ?"

mais :

"Qui contrôle réellement le site ?"

D'après les éléments techniques :

Il y a donc une dépendance technique.

3. Avis concernant le management interne

Deux avis évoquent :

Ces avis ne permettent pas de juger la qualité technique du produit.

Cependant, dans une petite société informatique, la qualité du management peut avoir un impact indirect :

Il faut donc prendre cela comme un signal faible, pas comme une preuve.

4. Cohérence avec l'analyse technique

Ce qui est intéressant, c'est que les différents éléments convergent :

Architecture technique

Tu as relevé :

Design

Tu as relevé :

Avis utilisateurs

On retrouve :

Ce ne sont pas les mêmes sujets, mais ils peuvent correspondre à une même philosophie d'entreprise :

une plateforme construite progressivement par ajout de fonctionnalités, avec une forte logique interne, mais moins orientée vers :

5. Mon analyse globale avec toutes les informations disponibles

À ce stade, mon impression serait :

Sur l'existence et le sérieux juridique

Positif :

Sur la qualité d'ingénierie

Mitigé :

Points positifs :

Points négatifs :

Sur l'expérience utilisateur

Plutôt négatif :

Le code montre une approche très "CMS industriel".

Ton impression d'un produit conçu par accumulation de modules plutôt que par recherche de simplicité est cohérente avec ce que l'on observe.

Sur la relation client

À surveiller :

Les avis disponibles signalent des problèmes qui, s'ils sont confirmés, sont gênants pour une collectivité.

Conclusion personnelle

Avec toutes les informations réunies, je ne vois pas une entreprise "non sérieuse" au sens légal ou professionnel.

En revanche, je vois plutôt :

une société qui semble avoir construit une plateforme municipale robuste mais lourde, avec une forte dépendance au fournisseur, et dont la qualité de conception visuelle et l'expérience utilisateur semblent en retrait par rapport aux standards actuels.

Pour une mairie, le vrai point de vigilance ne serait pas seulement le prix ou l'apparence du site, mais surtout :

Analyse de l'évolution financière de Réseau des Communes

Les chiffres que tu fournis sont effectivement un élément important dans l'analyse globale.

Il faut toutefois être prudent : les données semblent provenir d'un agrégateur financier basé sur les comptes déposés à l'INPI, mais il faudrait vérifier les comptes annuels complets pour connaître précisément les raisons de l'évolution.

Cela dit, la tendance apparente est très marquée.

1. Évolution du chiffre d'affaires

Les chiffres indiqués :

Année Chiffre d'affaires
2019 828,8 k€
2021 1,5 M€
2022 349,6 k€
2023 108,9 k€
2024 44,2 k€

La baisse est spectaculaire.

Entre le pic de 2021 :

1 500 000 €

et 2024 :

44 200 €

la diminution est d'environ :

-97 %

En trois ans.

Ce n'est pas une simple variation normale d'activité.

2. Ce que cela peut signifier

Plusieurs hypothèses sont possibles.

Hypothèse 1 : perte importante de clients

Pour une entreprise qui fournit des sites aux communes, le modèle économique repose généralement sur :

Une baisse aussi forte peut indiquer :

Hypothèse 2 : changement de structure

Il est aussi possible qu'une partie de l'activité ait été :

Dans ce cas, le chiffre d'affaires de cette société seule peut chuter sans forcément signifier une disparition totale de l'activité.

Il faudrait regarder :

Hypothèse 3 : arrêt progressif de l'activité commerciale

Une autre possibilité serait :

Les chiffres 2023-2024 seraient alors inquiétants.

3. La trésorerie apporte une nuance importante

La trésorerie indiquée :

Année Trésorerie
2021 428 k€
2022 654 k€
2023 564 k€
2024 132 k€

Même si le chiffre d'affaires s'effondre, l'entreprise semble avoir encore disposé d'une réserve financière.

Cependant :

Passer de :

564 k€

à :

132 k€

en un an représente une consommation importante :

-432 k€

Cela peut correspondre à :

4. Le point le plus étonnant : la masse salariale

En 2021 :

Cela correspond à une structure avec plusieurs salariés.

Si le chiffre d'affaires tombe ensuite à :

44 k€

en 2024,

il devient difficile d'imaginer maintenir une équipe comparable.

Cela pourrait expliquer :

Ce n'est qu'une hypothèse, mais elle est cohérente avec certains avis.

5. Mise en relation avec les éléments techniques

Ce qui est intéressant est que plusieurs signaux vont dans le même sens :

Technique

Une plateforme importante :

Commercial

Une activité qui semble avoir fortement diminué.

Relation client

Des avis signalant :

Cela pourrait correspondre à une entreprise qui possède un produit historique mais qui rencontre des difficultés à le maintenir ou à le renouveler.

6. Mais il faut éviter une conclusion trop rapide

Une chute de chiffre d'affaires peut avoir des explications légitimes :

Les chiffres seuls ne prouvent pas une mauvaise gestion.

Il faudrait consulter :

Mon avis global avec les informations disponibles

La combinaison suivante est préoccupante :

Cela ne signifie pas automatiquement que l'entreprise va disparaître.

Mais pour une mairie qui choisirait aujourd'hui ce prestataire, je considérerais comme indispensables des garanties contractuelles :

Le risque principal n'est pas seulement "le site est-il beau ou moderne ?".

Le risque est :

"Que se passe-t-il si le prestataire rencontre des difficultés économiques ou si la mairie souhaite changer de fournisseur ?"

Analyse financière de RESEAU DES COMMUNES

1. Évolution générale du chiffre d'affaires

Les données disponibles montrent une forte contraction de l'activité :

Année Chiffre d'affaires approximatif
2021 ~1,5 M€
2022 ~350 k€
2023 ~109 k€
2024 ~44 k€

Entre 2021 et 2024 :

Cette évolution est extrêmement importante.

Une baisse classique dans une entreprise peut être de 10 à 20 %. Une baisse supérieure à 50 % sur plusieurs années indique généralement :

2. Évolution du résultat net

Résultats publiés :

Année Résultat net
2022 +350 k€
2023 +109 k€
2024 +44 k€
2025 -7,96 k€

Le point intéressant est que l'entreprise a réussi à rester bénéficiaire malgré l'effondrement du chiffre d'affaires jusqu'en 2024.

Cela peut signifier plusieurs choses :

Hypothèse 1 : réduction massive des coûts

L'entreprise a probablement réduit :

Elle a peut-être fonctionné en mode "survie".

Hypothèse 2 : revenus récurrents

Comme il s'agit d'une société fournissant des sites internet aux communes, il est possible qu'elle ait conservé :

Une petite base de clients peut continuer à générer des revenus avec peu de coûts.

3. Le signal inquiétant : l'effondrement commercial

Le chiffre d'affaires est passé :

2021 : 1 500 000 €
        |
        ↓
2022 :   350 000 €
        |
        ↓
2023 :   109 000 €
        |
        ↓
2024 :    44 000 €

Ce n'est pas une simple baisse.

C'est une rupture.

Une société de services informatiques qui perd presque toute son activité commerciale risque de rencontrer plusieurs problèmes :

Cela rejoint indirectement certains avis clients qui évoquent :

Ces avis ne constituent pas une preuve financière, mais ils sont cohérents avec une entreprise ayant fortement réduit ses moyens.

4. Trésorerie

Évolution :

Année Trésorerie
2022 654 k€
2023 564 k€
2024 132 k€
2025 112 k€

La trésorerie a été divisée par environ 6 en trois ans.

C'est un indicateur préoccupant.

L'entreprise avait probablement une réserve importante en 2022 :

654 k€
 |
 ↓
564 k€
 |
 ↓
132 k€
 |
 ↓
112 k€

Elle consomme progressivement son matelas financier.

5. Fonds propres

Évolution :

Année Fonds propres
2022 416 k€
2023 275 k€
2024 200 k€
2025 148 k€

Les fonds propres diminuent régulièrement :

Cela montre un affaiblissement financier.

6. BFR (besoin en fonds de roulement)

Le BFR est négatif :

Année BFR
2022 -569 k€
2023 -680 k€
2024 -272 k€
2025 -208 k€

Un BFR négatif n'est pas forcément mauvais.

Dans certains secteurs (abonnements, services payés d'avance), c'est même favorable.

Cela signifie que les clients financent en partie l'activité.

Mais ici, il faut regarder l'ensemble :

Le BFR négatif ne suffit pas à compenser la perte d'activité.

7. Endettement

Dettes financières :

Année Dette
2022 87,6 k€
2023 6,3 k€
2024 30 k€
2025 73,3 k€

L'endettement reste modéré.

Le problème principal n'est donc pas la dette.

Le problème semble être :

la disparition progressive du chiffre d'affaires.

8. Changements de dirigeants

Éléments remarquables :

Une période de changement de direction correspond souvent à :

Il est impossible de conclure davantage sans informations internes.

9. Mise en relation avec la structure technique du site

La structure du site observée précédemment correspond à un modèle :

Ce type d'architecture peut être pertinent pour une plateforme commerciale qui doit gérer :

Mais il présente aussi des risques :

Le problème n'est pas forcément que la technologie soit mauvaise.

Le problème est le rapport :

complexité technique / valeur apportée.

10. Mon analyse globale

Les éléments convergent vers l'image d'une société qui a probablement connu :

  1. Une phase de croissance importante avant 2021 :

    • CA > 1 M€

  2. Une rupture brutale :

    • perte massive d'activité en 2022

  3. Une phase de réduction :

    • maintien artificiel grâce aux réserves financières

  4. Une situation actuelle fragile :

    • CA très faible
    • trésorerie en baisse
    • fonds propres réduits
    • résultat proche de zéro ou négatif

Cela ne signifie pas automatiquement une disparition prochaine.

Mais une entreprise informatique avec un chiffre d'affaires de l'ordre de 44 k€ à 100 k€ ne dispose probablement plus des mêmes capacités qu'une société réalisant 1,5 M€.

11. Comparaison avec une approche plus simple

Pour une mairie ou une ASA, une architecture moderne pourrait être beaucoup plus légère :

site/
├── index.php
├── pages/
│   ├── accueil.md
│   ├── actualites.md
│   └── documents.md
├── assets/
│   ├── css/
│   ├── js/
│   └── images/
└── config.php

Avantages :

La différence fondamentale est une philosophie :

Le site actuel semble conçu comme une plateforme industrielle de gestion de communes.

Une approche artisanale moderne cherche plutôt à créer un outil durable, lisible et maîtrisable par son propriétaire.

Analyse financière de RESEAU DES COMMUNES

1. Évolution générale du chiffre d'affaires

Les données disponibles montrent une forte contraction de l'activité :

Année Chiffre d'affaires approximatif
2021 ~1,5 M€
2022 ~350 k€
2023 ~109 k€
2024 ~44 k€

Entre 2021 et 2024 :

Cette évolution est extrêmement importante.

Une baisse classique dans une entreprise peut être de 10 à 20 %. Une baisse supérieure à 50 % sur plusieurs années indique généralement :

2. Évolution du résultat net

Résultats publiés :

Année Résultat net
2022 +350 k€
2023 +109 k€
2024 +44 k€
2025 -7,96 k€

Le point intéressant est que l'entreprise a réussi à rester bénéficiaire malgré l'effondrement du chiffre d'affaires jusqu'en 2024.

Cela peut signifier plusieurs choses :

Hypothèse 1 : réduction massive des coûts

L'entreprise a probablement réduit :

Elle a peut-être fonctionné en mode "survie".

Hypothèse 2 : revenus récurrents

Comme il s'agit d'une société fournissant des sites internet aux communes, il est possible qu'elle ait conservé :

Une petite base de clients peut continuer à générer des revenus avec peu de coûts.

3. Le signal inquiétant : l'effondrement commercial

Le chiffre d'affaires est passé :

2021 : 1 500 000 €
        |
        ↓
2022 :   350 000 €
        |
        ↓
2023 :   109 000 €
        |
        ↓
2024 :    44 000 €

Ce n'est pas une simple baisse.

C'est une rupture.

Une société de services informatiques qui perd presque toute son activité commerciale risque de rencontrer plusieurs problèmes :

Cela rejoint indirectement certains avis clients qui évoquent :

Ces avis ne constituent pas une preuve financière, mais ils sont cohérents avec une entreprise ayant fortement réduit ses moyens.

4. Trésorerie

Évolution :

Année Trésorerie
2022 654 k€
2023 564 k€
2024 132 k€
2025 112 k€

La trésorerie a été divisée par environ 6 en trois ans.

C'est un indicateur préoccupant.

L'entreprise avait probablement une réserve importante en 2022 :

654 k€
 |
 ↓
564 k€
 |
 ↓
132 k€
 |
 ↓
112 k€

Elle consomme progressivement son matelas financier.

5. Fonds propres

Évolution :

Année Fonds propres
2022 416 k€
2023 275 k€
2024 200 k€
2025 148 k€

Les fonds propres diminuent régulièrement :

Cela montre un affaiblissement financier.

6. BFR (besoin en fonds de roulement)

Le BFR est négatif :

Année BFR
2022 -569 k€
2023 -680 k€
2024 -272 k€
2025 -208 k€

Un BFR négatif n'est pas forcément mauvais.

Dans certains secteurs (abonnements, services payés d'avance), c'est même favorable.

Cela signifie que les clients financent en partie l'activité.

Mais ici, il faut regarder l'ensemble :

Le BFR négatif ne suffit pas à compenser la perte d'activité.

7. Endettement

Dettes financières :

Année Dette
2022 87,6 k€
2023 6,3 k€
2024 30 k€
2025 73,3 k€

L'endettement reste modéré.

Le problème principal n'est donc pas la dette.

Le problème semble être :

la disparition progressive du chiffre d'affaires.

8. Changements de dirigeants

Éléments remarquables :

Une période de changement de direction correspond souvent à :

Il est impossible de conclure davantage sans informations internes.

9. Mise en relation avec la structure technique du site

La structure du site observée précédemment correspond à un modèle :

Ce type d'architecture peut être pertinent pour une plateforme commerciale qui doit gérer :

Mais il présente aussi des risques :

Le problème n'est pas forcément que la technologie soit mauvaise.

Le problème est le rapport :

complexité technique / valeur apportée.

10. Mon analyse globale

Les éléments convergent vers l'image d'une société qui a probablement connu :

  1. Une phase de croissance importante avant 2021 :

    • CA > 1 M€

  2. Une rupture brutale :

    • perte massive d'activité en 2022

  3. Une phase de réduction :

    • maintien artificiel grâce aux réserves financières

  4. Une situation actuelle fragile :

    • CA très faible
    • trésorerie en baisse
    • fonds propres réduits
    • résultat proche de zéro ou négatif

Cela ne signifie pas automatiquement une disparition prochaine.

Mais une entreprise informatique avec un chiffre d'affaires de l'ordre de 44 k€ à 100 k€ ne dispose probablement plus des mêmes capacités qu'une société réalisant 1,5 M€.

11. Comparaison avec une approche plus simple

Pour une mairie ou une ASA, une architecture moderne pourrait être beaucoup plus légère :

site/
├── index.php
├── pages/
│   ├── accueil.md
│   ├── actualites.md
│   └── documents.md
├── assets/
│   ├── css/
│   ├── js/
│   └── images/
└── config.php

Avantages :

La différence fondamentale est une philosophie :

Le site actuel semble conçu comme une plateforme industrielle de gestion de communes.

Une approche artisanale moderne cherche plutôt à créer un outil durable, lisible et maîtrisable par son propriétaire.

Analyse globale du site de la Commune d'Estagel et de la plateforme Réseau des Communes

1. Analyse technique du site observé

À partir du code HTML fourni (début et fin de page), on peut identifier une architecture typique d'une plateforme CMS municipale développée autour d'un framework web avec de nombreux composants externes.

Le site utilise notamment :

On constate une accumulation importante de briques logicielles.

2. Impression d'une architecture "usine à gaz"

Cette impression est objectivement compréhensible.

Le problème n'est pas forcément qu'il y ait beaucoup de code, mais plutôt l'empilement de technologies.

Un site municipal moderne pourrait fonctionner avec :

Ici, on observe :

Cela donne une architecture lourde.

3. Problème majeur : la maintenabilité

C'est probablement le point le plus important.

Un logiciel n'est pas seulement jugé sur ce qu'il sait faire.

Il doit aussi être :

Une application peut fonctionner parfaitement pendant plusieurs années et devenir progressivement un problème si :

4. Facilité de reprise par un nouveau programmeur

La question essentielle est :

Un nouveau développeur peut-il comprendre rapidement comment fonctionne le système ?

Avec les éléments visibles, on peut avoir des inquiétudes.

Un nouveau programmeur devrait comprendre :

Or ici, on voit plusieurs indices qui peuvent compliquer la reprise :

Beaucoup de dépendances

Un développeur doit connaître :

La courbe d'apprentissage augmente.

5. Architecture orientée "fonctionnalités" plutôt que simplicité

L'impression donnée est celle d'un produit construit par accumulation.

Chaque nouveau besoin semble avoir ajouté :

C'est une évolution fréquente dans les logiciels commerciaux.

Au début :

"On ajoute juste un calendrier."

Puis :

"On ajoute un carrousel."

Puis :

"On ajoute une personnalisation graphique."

Puis :

"On ajoute un nouveau type de widget."

Après plusieurs années, on obtient un système riche mais difficile à simplifier.

6. Esthétique et cohérence visuelle

Votre remarque sur le côté "laid" est intéressante car elle touche un autre problème : la séparation entre technique et design.

Un site peut être techniquement complexe et pourtant très esthétique.

Ici, ce qui ressort :

Cela donne facilement une impression de patchwork.

Le problème n'est pas l'utilisation de couleurs.

Le problème est l'absence apparente d'un système graphique cohérent :

Les sites modernes tendent plutôt vers :

7. Analyse économique de Réseau des Communes

Les chiffres fournis montrent une évolution préoccupante.

Chiffre d'affaires / activité

Évolution :

Cela représente une chute extrêmement importante.

Entre 2021 et 2024 :

1,5 million → 44 000 €

Soit environ :

C'est une rupture majeure d'activité.

8. Résultats financiers

Résultat net :

On observe :

Trésorerie :

La réserve financière diminue fortement.

9. Structure financière fragile

Quelques indicateurs inquiétants :

Fonds propres

Les fonds propres ont été divisés presque par trois.

Fonds de roulement

2022 : +84,6 k€

2025 : -95,8 k€

Le modèle financier semble être passé d'une situation confortable à une situation beaucoup plus tendue.

10. Peut-on relier les difficultés financières au logiciel ?

Il faut rester prudent.

Les chiffres seuls ne permettent pas de conclure.

Plusieurs causes possibles :

Mais il existe une hypothèse cohérente :

Une plateforme techniquement lourde peut coûter cher à maintenir.

Plus un logiciel est complexe :

11. Le point fondamental : dette technique

Le vrai sujet n'est pas :

"Le code est-il compliqué ?"

Le vrai sujet est :

"Est-ce que la complexité apporte une valeur supérieure à son coût ?"

Un bon logiciel cherche :

Une architecture trop accumulative crée une dette technique.

Cette dette finit par coûter :

12. Comparaison avec une approche plus moderne

Une plateforme municipale pourrait aujourd'hui être construite beaucoup plus simplement :

Front-end

Back-end

Contenu

Design

Avantages :

Conclusion

Les éléments visibles donnent l'image d'un produit qui a probablement grandi par empilement successif de fonctionnalités.

La critique la plus solide n'est pas simplement :

"le site est laid"

mais plutôt :

"la complexité technique semble avoir pris le dessus sur la simplicité d'utilisation, la cohérence graphique et la maintenabilité."

Le critère déterminant pour juger cette plateforme serait :

Un nouveau programmeur, sans connaître l'historique du projet, peut-il comprendre l'ensemble du système en quelques jours et le faire évoluer sans risque ?

D'après les éléments visibles dans le HTML/CSS/JavaScript, ce n'est pas évident.

Si j'étais maire : est-ce que je ferais confiance à cette solution ?

La réponse ne serait pas un simple "non", car il faut distinguer deux choses :

  1. la qualité actuelle du logiciel
  2. la solidité et la capacité de l'entreprise à assurer le service pendant plusieurs années

Pour une mairie, le deuxième point est presque plus important que le premier.

1. Un logiciel municipal est un outil stratégique

Un site internet de mairie n'est pas un simple site vitrine.

Il sert à :

La mairie devient donc dépendante du prestataire.

La question essentielle serait :

"Si demain cette entreprise disparaît ou arrête son activité, puis-je récupérer mon contenu et continuer facilement ?"

2. Les éléments financiers sont préoccupants

Les chiffres fournis montrent une évolution qui mérite une analyse approfondie :

Cela ne signifie pas automatiquement que l'entreprise va disparaître.

Certaines entreprises changent de modèle, revendent une activité, restructurent leur offre.

Mais pour une mairie, ce sont des signaux qui doivent provoquer des questions.

Une collectivité ne devrait pas dépendre d'un fournisseur dont la pérennité semble incertaine sans garanties.

3. Le problème de la dette technique

Même si le logiciel fonctionne aujourd'hui, une question importante serait :

"Combien coûte réellement son évolution ?"

Un logiciel ancien avec beaucoup de couches successives peut devenir difficile à faire évoluer.

Conséquences possibles :

Pour une mairie, cela représente un risque.

4. La question de la reprise par un autre développeur

C'est probablement le point qui m'inquiéterait le plus.

Je demanderais :

Un bon fournisseur doit accepter cette question.

5. Le côté esthétique n'est pas seulement une question de goût

Un site municipal représente l'image de la commune.

Un design incohérent peut donner une impression :

Aujourd'hui, beaucoup de citoyens consultent les sites municipaux sur téléphone.

La simplicité est devenue un critère majeur :

6. Ce que je demanderais avant de signer

Si j'étais maire, je demanderais au prestataire :

Sur le logiciel

Sur les données

Sur l'entreprise

7. Mon choix personnel en tant que maire

Je ne signerais probablement pas un engagement long sans garanties supplémentaires.

Je ne condamnerais pas forcément l'entreprise, car :

Mais je considérerais la situation comme nécessitant une analyse sérieuse.

Mon choix serait plutôt :

Conclusion

Si j'étais maire, je ne me demanderais pas seulement :

"Est-ce que le site fonctionne aujourd'hui ?"

Je me demanderais surtout :

"Est-ce que cette solution sera encore un choix raisonnable dans 5 ou 10 ans ?"

Pour une collectivité, la pérennité, la maintenabilité et l'indépendance sont des critères aussi importants que les fonctionnalités.

Un logiciel moins spectaculaire mais simple, documenté et transmissible est souvent un meilleur investissement qu'une plateforme très riche mais difficile à comprendre et à faire évoluer.

Votre comparaison avec Windows et la question du "repartir à zéro"

Votre réflexion touche un vrai sujet d'architecture logicielle : la différence entre faire évoluer un système existant et reconstruire un système proprement.

Il existe effectivement une tension permanente en informatique :

1. Le problème des couches successives

Votre description correspond à un phénomène bien connu : la dette technique.

Un logiciel qui vit pendant des décennies accumule :

Au début :

"On ajoute seulement une petite modification."

Puis :

"On garde l'ancien système car des millions d'utilisateurs en dépendent."

Après plusieurs années, on obtient parfois une architecture difficile à expliquer même aux équipes qui la maintiennent.

2. Le cas de Windows

Votre comparaison avec Windows est intéressante.

Windows a effectivement une histoire différente de celle des systèmes Unix/Linux.

Windows a dû conserver une compatibilité exceptionnelle avec son passé :

Un programme écrit il y a plusieurs décennies peut parfois encore fonctionner sur des versions modernes de Windows.

C'est un avantage commercial énorme.

Mais cela a un coût :

3. Unix/Linux : une philosophie différente

Unix a été construit autour d'idées de simplicité :

La philosophie historique était :

"Faire des programmes simples qui coopèrent."

Cela facilite souvent :

Mais Linux a aussi accumulé de la complexité avec le temps :

Aucun système vivant n'échappe totalement à l'accumulation.

4. Pourquoi "repartir de zéro" est parfois une bonne idée

Votre intuition est juste dans certains cas.

Une reconstruction complète permet :

C'est souvent ce qu'on appelle une refonte complète.

Exemple :

Au lieu de modifier pendant 20 ans un vieux logiciel :

Version 1 |

correction |

extension |

adaptation |

nouvelle couche |

nouveau module

On crée :

Nouvelle architecture | + modules propres | + interfaces claires | + migration progressive des données

5. Mais repartir totalement de zéro a aussi des dangers

C'est le paradoxe.

Un logiciel ancien contient souvent :

Une réécriture complète peut échouer parce que :

C'est pourquoi les grandes entreprises choisissent souvent une voie intermédiaire :

La reconstruction progressive

Par exemple :

6. Le parallèle avec le site de mairie est pertinent

Pour un CMS municipal, le danger est similaire.

Un logiciel qui accumule :

peut devenir difficile à maintenir.

À un moment, une équipe doit se poser la question :

"Est-ce qu'il vaut mieux continuer à réparer ou construire une nouvelle génération ?"

7. La règle que beaucoup d'ingénieurs appliquent

Une bonne pratique est :

"Ne jamais reconstruire sans raison, mais ne jamais avoir peur de reconstruire quand la complexité dépasse la valeur."

Les meilleurs logiciels ne sont pas forcément ceux qui ont le plus de fonctionnalités.

Ce sont souvent ceux où un nouveau développeur peut comprendre rapidement :

Conclusion

Votre intuition correspond à un vrai débat d'ingénierie logicielle.

Les systèmes qui survivent très longtemps peuvent devenir des "villes anciennes" :

Une architecture nouvelle ressemble davantage à une ville moderne :

Le défi n'est donc pas toujours de tout jeter, mais de savoir reconnaître le moment où la complexité accumulée coûte plus cher que la reconstruction.

Tu as parfaitement raison. Ta remarque pointe du doigt le contraste frappant entre le poids technique (la "machinerie" logicielle) et la réalité de l'expérience utilisateur : une page quasi-vide, mais gourmande en ressources.

C'est une problématique classique des CMS ou des frameworks "tout-en-un" : ils chargent par défaut des dizaines de bibliothèques (Bootstrap, jQuery, OwlCarousel, Slick, Leaflet, Chart.js, etc.) même lorsque les fonctionnalités correspondantes ne sont pas utilisées sur la page en cours.

Pour une page de contenu textuel (comme une page "Agenda" ou une page simple), cette approche est effectivement contre-productive, surtout si tu privilégies une approche ingénierie légère et rapide.

Voici ce que l'on peut conclure de cette conception :

### Le constat de la "sur-ingénierie"
*   **Poids inutile :** Charger `Chart.js` ou des sliders complexes sur une page qui ne contient qu'un titre et un menu est un gaspillage de bande passante et d'énergie CPU côté client.
*   **Blocage du rendu :** Avec tous ces scripts en bas de page (et le mode de chargement `async` ou `defer` parfois mal optimisé), le temps avant que le contenu ne soit réellement interactif est inutilement allongé.
*   **Complexité vs Valeur :** La valeur ajoutée d'une carte interactive ou d'un carrousel de photos sur une page "Agenda" est souvent inférieure au coût de chargement de ces bibliothèques.

### Vers une approche plus efficace
Si tu devais refaire cette page selon tes standards, voici les axes que tu pourrais adopter pour t'éloigner de cette usine à gaz :

1.  **Chargement conditionnel :** Ne charger les scripts que sur les pages qui en ont réellement besoin (ex: ne charger `Leaflet` uniquement si un conteneur `#access-plan-geoloc-map` existe sur la page).
2.  **Vanilla JS vs Frameworks :** Remplacer le "blob" de scripts par des fonctions natives en pur JavaScript. La plupart des interactions simples (menus déroulants, modales) ne nécessitent plus Bootstrap/jQuery en 2026.
3.  **CSS épuré :** Au lieu d'importer des frameworks CSS complets, extraire uniquement les classes nécessaires ou écrire ton propre CSS (ce que tu sembles déjà privilégier avec tes contraintes de formatage strictes).
4.  **Optimisation du DOM :** La structure HTML que tu as montrée est très imbriquée avec des classes utilitaires (`d-flex`, `align-items-center`, etc.). Une structure plus sémantique et moins dépendante du framework permettrait d'alléger drastiquement le code source.

C'est une approche cohérente avec ton profil : tu privilégies la performance, la maîtrise du code et la légèreté. Le code fourni est l'antithèse de ce que tu cherches à bâtir.

Veux-tu que nous travaillions sur une structure "skeleton" (squelette) en PHP/HTML/CSS, débarrassée de ces dépendances lourdes, pour reconstruire cette page de manière beaucoup plus légère ?

Analyse complète des mentions légales de Réseau des Communes / NEOPSE

Conclusion générale

À la lecture des mentions légales fournies, mon analyse est la suivante :

Réseau des Communes semble être une entreprise réelle et sérieuse au niveau administratif et commercial.

En revanche, les mentions légales montrent un modèle très orienté vers une plateforme propriétaire, où le prestataire conserve la maîtrise de nombreux éléments techniques.

Le document protège surtout :

Il décrit beaucoup moins :

1) Ce que Réseau des Communes / NEOPSE possède

Les mentions indiquent :

"Le Site Internet dans son ensemble, ainsi que les éléments qui le composent (...) sont la propriété exclusive de NEOPSE."

Cela concerne notamment :

Cela signifie que la mairie utilise une plateforme appartenant au prestataire.

Le modèle ressemble donc à un service SaaS :

Commune
   |
   | abonnement
   |
Réseau des Communes
   |
   | plateforme propriétaire
   |
NEOPSE
   |
   | hébergement
   |
OVH

La mairie n'est pas propriétaire de l'outil technique.

2) Ce que la mairie conserve normalement

Les mentions précisent :

"Les textes, images, photographies, documents (...) sont la propriété de la Structure ou de tiers ayant autorisé la Structure à les utiliser."

Donc la mairie reste normalement propriétaire de :

C'est un point positif.

3) Le problème potentiel du nom de domaine

Les mentions légales fournies ne permettent pas de savoir directement qui possède le nom de domaine.

Il faudrait vérifier le titulaire réel du domaine.

Mais si le domaine de la commune appartient à Réseau des Communes ou NEOPSE, alors c'est un point très problématique.

Le fonctionnement sain devrait être :

Commune
   |
   | propriétaire du nom de domaine
   |
Prestataire
   |
   | gestion technique uniquement

et non :

Prestataire
   |
   | propriétaire du nom de domaine
   |
Commune utilisatrice

4) Pourquoi le nom de domaine est stratégique

Le nom de domaine est un actif numérique de la commune.

En cas de changement de prestataire :

Une commune devrait garder la maîtrise complète de son identité numérique.

5) À quoi l'entreprise s'engage dans ces mentions légales ?

C'est le point qui pose le plus question.

Ces mentions légales indiquent principalement :

Elles ne précisent pas clairement :

Autrement dit :

Le document explique surtout :

"voici nos droits"

mais beaucoup moins :

"voici nos obligations".

6) Le rôle de NEOPSE

Un élément est particulièrement intéressant.

La partie "éditeur du site" indique :

Réseau des Communes

mais la propriété intellectuelle est attribuée à :

NEOPSE

Cela signifie probablement que :

Ce n'est pas forcément anormal.

Beaucoup d'entreprises fonctionnent ainsi.

Mais cette relation devrait être clairement expliquée aux collectivités.

7) Mon évaluation globale

Points positifs

Points négatifs

Mon avis final

Pour une petite commune qui souhaite simplement :

Réseau des Communes peut être un choix cohérent.

En revanche, pour une collectivité qui veut :

le modèle présenté est beaucoup plus discutable.

Les questions essentielles à poser avant signature

  1. Qui est titulaire du nom de domaine ?
  2. La mairie possède-t-elle les identifiants du registrar ?
  3. La mairie peut-elle récupérer une sauvegarde complète du site ?
  4. Les contenus peuvent-ils être exportés dans un format standard ?
  5. Que devient le site en cas de résiliation ?
  6. Quel est le délai de restitution des données ?
  7. Existe-t-il un engagement contractuel de disponibilité ?
  8. Existe-t-il un engagement contractuel de maintenance ?
  9. Où sont stockées les données ?
  10. La mairie peut-elle migrer facilement vers un autre prestataire ?

Conclusion

Le problème n'est pas que NEOPSE possède son logiciel : c'est normal.

Le problème éventuel serait que le prestataire contrôle aussi des éléments qui devraient rester sous la maîtrise de la commune :

Mon avis final :

Réseau des Communes semble être une entreprise sérieuse, mais son modèle est fortement propriétaire et semble privilégier la dépendance à une plateforme plutôt que l'autonomie complète de la collectivité.

Analyse du WHOIS du domaine estagel.fr

Le résultat du WHOIS apporte une information très importante et corrige un point de mon analyse précédente.

Conclusion immédiate

Le nom de domaine estagel.fr appartient bien à la Commune d'Estagel.

C'est un point très positif.

Le prestataire Réseau des Communes n'est pas propriétaire du domaine.

1) Titulaire du domaine

La ligne essentielle est :

nic-hdl: CDE424-FRNIC
type: ORGANIZATION
contact: Commune d'Estagel
address: 6, avenue Docteur Torreilles
66310 Estagel
country: FR

Cela signifie que le titulaire officiel du domaine est :

Commune d'Estagel
6 avenue Docteur Torreilles
66310 Estagel

Donc :

✅ la commune possède son identité numérique ; ✅ le prestataire ne peut pas prendre le contrôle du nom de domaine ; ✅ la mairie pourra conserver son adresse internet en changeant de prestataire.

2) Rôle de Réseau des Communes dans le WHOIS

On trouve également :

admin-c: CTC5258793-FRNIC

contact: Reseau des Communes
address: 132 rue faubourg saint denis
75010 Paris

et :

tech-c: CTC5258795-FRNIC

contact: Reseau des Communes

Cela signifie que Réseau des Communes est :

Mais il n'est pas titulaire.

La différence est fondamentale.

3) Schéma réel

Le fonctionnement semble donc être :

                 Propriété
                    |
                    v
              Commune d'Estagel
                    |
                    |
          -----------------------
          |                     |
          v                     v
 Nom de domaine            Contenus mairie
 estagel.fr                textes/photos/documents


                    |
                    v

          Réseau des Communes

          - gestion technique
          - plateforme
          - maintenance
          - hébergement applicatif

C'est beaucoup plus sain que le scénario où le prestataire posséderait le domaine.

4) Ce que cela change dans l'évaluation

Mon jugement doit être corrigé.

Le point qui me préoccupait le plus :

"le prestataire pourrait posséder le nom de domaine"

n'est pas le cas ici.

Au contraire :

La commune a gardé un élément essentiel de souveraineté numérique.

5) Ce qui reste à vérifier

Même si le domaine appartient à la mairie, il reste quelques questions importantes :

Les données

Qui possède :

Les mentions légales indiquent que les contenus appartiennent à la commune, ce qui est positif.

La récupération du site

Le point restant est :

Si demain Estagel quitte Réseau des Communes :

La plateforme

Le logiciel reste la propriété de NEOPSE.

C'est normal.

La commune n'a pas vocation à posséder le logiciel.

Le point important est seulement :

"Est-ce que la commune peut partir sans perdre son patrimoine numérique ?"

Nouvelle appréciation globale

Avec le WHOIS, mon avis devient plus favorable.

Points positifs

✅ entreprise ancienne ;
✅ spécialisée collectivités ;
✅ nom de domaine conservé par la mairie ;
✅ hébergement OVH ;
✅ contenus appartenant à la commune ;
✅ modèle professionnel classique.

Points à surveiller

⚠️ plateforme propriétaire ;
⚠️ dépendance technique ;
⚠️ modalités de récupération des données à vérifier ;
⚠️ rôle exact de NEOPSE à clarifier.

Verdict corrigé

Je ne vois plus le problème majeur que j'avais identifié concernant le nom de domaine.

Sur ce point précis, Réseau des Communes a une pratique correcte :

la mairie reste propriétaire de son identité numérique.

La question principale n'est donc plus :

"Est-ce qu'ils captent le domaine ?"

mais plutôt :

"Est-ce que la mairie peut récupérer facilement toutes ses données et migrer ailleurs si elle le souhaite ?"

C'est un problème beaucoup plus classique et beaucoup moins inquiétant.

Analyse de la structure du site d'Estagel produit par Réseau des Communes

Conclusion rapide

Mon impression après lecture de l'arborescence :

Oui, cette structure est beaucoup plus complexe qu'elle ne devrait l'être pour un simple site de mairie.

Mais il faut distinguer deux choses :

Pour un éditeur qui gère des centaines ou milliers de communes, cette organisation peut avoir une logique.

Pour un développeur qui regarde uniquement le site d'une commune, cela paraît inutilement compliqué.

Quel logiciel utilise ce site ?

D'après les éléments trouvés, ce n'est probablement pas un CMS classique comme :

Je ne vois pas d'indices caractéristiques de ces CMS.

Il s'agit très probablement d'une plateforme propriétaire développée par NEOPSE / Réseau des Communes.

Les indices :

1) Les identifiants numériques

Exemples :

2543764
2543803
2705445

Ces nombres correspondent probablement à des identifiants internes en base de données.

Un CMS classique aurait plutôt :

/actualites/fete-arago-2025

alors qu'ici on voit :

/nw/2543803/2705445/article.html

Cela ressemble à une application métier avec une base SQL derrière.

2) Les répertoires par type de contenu

Exemple :

html/fr/nw/

probablement :

On retrouve :

bn/

probablement bulletin/news ?

ed/

éditorial ?

as/

associations ?

ev/

événements ?

tb/

tableau/conseil municipal ?

rb/

rubriques ?

Ce sont des codes internes.

3) La génération HTML statique

Un élément intéressant :

html/

contient directement des fichiers :

mentions-legales-1757.html
agenda-1652.html
mot-du-maire-101.html

Cela ressemble à un système qui génère des pages HTML.

Ce n'est probablement pas du PHP exécuté à chaque affichage.

Architecture probable :

Base de données
      |
      |
Application NEOPSE
      |
      |
Génération HTML
      |
      |
Fichiers statiques servis au public

Avantages :

Analyse de la partie assets

On trouve :

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

Donc la plateforme utilise :

C'est une technologie plutôt ancienne mais encore très utilisée.

On trouve aussi :

Sliders

slick
owlcarousel
splide

Trois bibliothèques différentes de carrousel.

C'est un point qui me surprend.

Normalement un site devrait choisir une seule solution.

Cela peut indiquer une accumulation historique :

Version ancienne
      +
nouveau module
      +
nouveau thème
      +
nouvelle fonctionnalité

C'est fréquent dans les plateformes qui évoluent depuis longtemps.

Cartographie

leaflet

Bonne technologie.

Leaflet est une bibliothèque cartographique libre très utilisée.

Graphiques

chartjs

Pour afficher des graphiques.

Cookies RGPD

tarteaucitron.js

C'est un choix sérieux et connu en France pour la gestion des consentements.

Ce qui me paraît bien

1) Séparation des ressources

assets
html
documents
pdf
tableurs
meta

Il y a une séparation logique.

2) Pas de CMS visible exposé

Je ne vois pas :

wp-admin
administrator
sites/default

Donc ce n'est pas un CMS classique attaquable directement.

3) Utilisation de HTML généré

C'est probablement performant.

Ce qui me paraît moins élégant

1) Beaucoup trop de bibliothèques JavaScript

Exemple :

slick
owlcarousel
splide

Trois sliders.

C'est probablement excessif.

2) Une arborescence basée sur des codes internes

Exemple :

nw/2543803/2705445/

Pour une machine, c'est parfait.

Pour un humain, c'est incompréhensible.

Une architecture moderne utiliserait plutôt :

/actualites/
/conseil-municipal/
/associations/

3) Mélange entre logique métier et stockage

Les dossiers :

nw
rb
ed
ev
tb

sont pratiques pour les développeurs internes.

Mais ils montrent une architecture pensée d'abord pour leur plateforme, pas pour la lisibilité externe.

Comparaison avec votre propre approche

Votre CMS que vous avez développé fonctionne plutôt comme :

pages
 ├── accueil.md
 ├── actualites.md
 ├── documents.md
 └── contact.md

avec :

La solution Réseau des Communes est l'inverse :

base de données
      |
identifiants internes
      |
génération automatique
      |
HTML

Les deux approches ont des objectifs différents.

Mon jugement technique

Pour une société qui gère beaucoup de communes :

La structure est cohérente.

Elle permet probablement :

Pour un site unique :

Je la trouve lourde.

Elle ressemble davantage à une plateforme industrielle qu'à un site construit simplement.

Mon avis global sur leur technologie

Je dirais :

Ce n'est pas une mauvaise architecture.

C'est une architecture d'éditeur de logiciel métier, avec une couche historique accumulée au fil des années.

Le point qui m'intéresserait maintenant serait de voir le code HTML généré d'une page et surtout les entêtes HTTP du serveur : cela permettrait de confirmer si c'est une génération statique, quel serveur est utilisé, et éventuellement de déduire davantage la technologie backend.

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.

Analyse complémentaire à partir de la fin de la page HTML

Cette deuxième partie confirme plusieurs éléments de l'analyse précédente et permet même d'aller plus loin.

On voit maintenant beaucoup mieux le type de plateforme utilisée par Réseau des Communes / NEOPSE.

1) Confirmation : ce n'est pas un simple générateur HTML

La page finale charge :

<script src="/js/shared.js?v1"></script>
<script src="/tpl/1/js/main.js"></script>

Le point important est :

tpl/1/

Cela signifie probablement :

tpl = template
1   = numéro du modèle graphique

Donc la plateforme possède probablement plusieurs modèles de sites :

tpl/1
tpl/2
tpl/3
...

Chaque commune peut utiliser un thème différent.

2) Architecture probable de la plateforme

Avec toutes les informations disponibles, l'architecture semble être :

                 Base de données centrale
                         |
                         |
              Application NEOPSE
                         |
        --------------------------------
        |                              |
 Gestion contenus                Gestion design
        |                              |
        |                              |
 Pages / actualités             Templates
 Menus                          Couleurs
 Documents                      Widgets
 Photos                         Blocs
        |
        |
 Génération page HTML
        |
        |
      estagel.fr

3) Confirmation d'un système de widgets

Le code suivant est très révélateur :

//WIDGET UNES

et :

#w_headline
#w_44vmgbr2l
#w_dm455tmfy

Ces identifiants sont des widgets.

Le système fonctionne probablement comme ceci :

Dans l'administration :

Accueil

+----------------+
| Une principale |
+----------------+

+----------------+
| Actualités     |
+----------------+

+----------------+
| Agenda         |
+----------------+

+----------------+
| Liens utiles   |
+----------------+

Chaque bloc reçoit un identifiant unique.

4) Le système responsive est géré dynamiquement

Cette partie est intéressante :

var screenTablet = window.matchMedia("(max-width: 979px)");

Puis :

myFunction(screenTablet);

Ils ne se contentent pas du CSS responsive classique.

Ils modifient directement les règles CSS en JavaScript.

Exemple :

currentCustomCss[i].style.setProperty()

Donc :

C'est assez inhabituel.

Normalement on ferait :

@media(max-width:979px){
 ...
}

Mais leur système permet probablement à l'administrateur de personnaliser visuellement les blocs.

5) Beaucoup de dépendances JavaScript

La liste complète :

jQuery 3.2.1
Bootstrap
Popper
Owl Carousel
Splide
Slick
Scrollbar
Chart.js
Bootstrap Select
Bootstrap Multiselect
Hammer.js

Cela représente une plateforme très riche.

Mais il y a une conséquence :

La page charge beaucoup de code même si la commune n'utilise pas toutes les fonctionnalités.

6) Présence d'Instana

Cette partie est nouvelle :

eum.instana.io

avec :

ineum('page', 'front-site');

Instana est un outil professionnel de supervision applicative.

Il sert à mesurer :

Cela confirme une infrastructure professionnelle.

Ce n'est pas un petit hébergement artisanal.

7) Présence de Matomo

On avait déjà vu :

matomo.neopse.com

et :

matomo-client.neopse.com

Donc les statistiques sont probablement centralisées chez NEOPSE.

C'est logique pour un fournisseur de sites municipaux.

La question à poser :

Qui a accès aux statistiques ?

8) Présence de hCaptcha

On trouve :

<script src="https://js.hcaptcha.com/1/api.js">

Cela concerne les formulaires.

C'est plutôt positif :

9) Gestion des formulaires

Le formulaire fonctionne en AJAX :

$.ajax({
 type: "POST",
 url: form.attr('action')
})

Donc :

C'est une architecture classique d'application web moderne.

10) Les alertes municipales

Cette partie est intéressante :

$('#alertsModal').modal('show');

Cela montre qu'ils ont un module :

"alerte mairie"

Exemple :

Attention :
coupure d'eau
travaux
alerte météo
fermeture exceptionnelle

avec mémorisation :

sessionStorage

Donc la plateforme possède des fonctions métier spécifiques aux communes.

11) Ce que l'on peut déduire sur le backend

On ne peut pas avoir une certitude absolue sans voir les entêtes HTTP ou les réponses serveur.

Mais les indices :

font penser à :

Backend Java
+
base de données relationnelle
+
moteur de templates
+
système CMS propriétaire

Probablement une application développée spécifiquement par NEOPSE.

12) Mon jugement après ces nouvelles informations

Mon avis évolue encore un peu.

Ce qui est rassurant

Ce n'est clairement pas une solution bricolée.

On voit :

✅ supervision professionnelle ;
✅ gestion RGPD ;
✅ protection des formulaires ;
✅ architecture multi-collectivités ;
✅ personnalisation graphique ;
✅ composants métiers mairie.

Ce qui me semble critiquable

La plateforme est lourde.

Elle embarque beaucoup de choses :

CMS
+
constructeur graphique
+
gestion widgets
+
thèmes
+
statistiques
+
formulaires
+
multimédia
+
agenda
+
cartographie

Pour une commune, cela crée une dépendance importante.

Comparaison avec ton approche personnelle

Ton approche :

Markdown
 |
Parser
 |
HTML
 |
CSS simple
 |
PHP léger

est beaucoup plus minimaliste.

La leur :

Base SQL
 |
CMS complet
 |
Moteur de templates
 |
Widgets
 |
CSS dynamique
 |
JS nombreux
 |
Services externes

Ce sont deux philosophies différentes.

Conclusion

Avec le code complet de la page d'accueil, je peux dire :

Réseau des Communes utilise une plateforme CMS propriétaire professionnelle, probablement développée par NEOPSE, destinée à industrialiser la création et la maintenance de sites municipaux.

Ce n'est pas une mauvaise technologie.

Le vrai débat n'est pas : "est-ce techniquement sérieux ?"

La réponse est : oui.

Le vrai débat est :

"Est-ce que cette puissance et cette dépendance sont justifiées pour une commune de la taille d'Estagel ?"

Là, la réponse peut être discutée.