Critères de Choix pour un site Internet

Cet article reprend une note mettant en évidence quelques critères (tant techniques qu’économiques ou même stratégiques), pour orienter le choix d’Internet, dans le cas d’une collectivité locale, mais certainement transposable a d’autres domaines....

Article publié le 19 juin 2014, et actualisé en juin 2014


 Comment fonctionnera le site Internet

Le site Internet doit (évidement) être inter-actif et souvent mis-à-jour, et les informations seront forcément surveillées, ou mieux explicitement validées par un cadre responsable : ceci induit un circuit de validation intégré au back-office de l’outil de publication de site Internet, et donc un lien avec les annuaires internes...
Car si vous voulez des données à jour, cela présuppose une saisie à la source d’émission, donc dans les services, et peut-être même à la place de circuits d’informations internes.... réorganisations en perspectives !!)

Le projet Site Internet devient donc un projet transversal à la collectivité, fédérateur, et pouvant facilement inclure d’autres intervenants extérieurs : la gestion de la sécurité peut conduire a créer en fait une juxtaposition de plusieurs dossiers Web mutualisés sous le même CMS (dans des zones de droits différents), et la même présentation (je préfèrerai parler d’apparence au niveau de la charte graphique visuelle, et garder le terme de présentation pour la structuration apparente des données, en termes sémantiques, c’est-à-dire quelles données sont effectivement affichées !)

Autant l’apparence releve de la Communication, autant la présentation c’est-à-dire le choix des données présentées, et l’ergonomie d’accès (respectant la règle des trois clics, mais aussi les diverses navigations par mot-clés) sont typiquement des problèmes informatiques, sans parler des modules et formulaires d’inter-activité.

Cette navigation est sans doute le point clé le plus difficile à résoudre pour un site de contenu, et plusieurs biais de cheminement par mots-clés sont à prévoir.

 Périmètre de couverture

Le choix d’un outil initial d’un site Internet ne se résout pas (mais pas du tout) à un simple problème de publication sur Internet, qui relèverait de la Communication sur Internet.

Meme si l’architecture Web offre une double liberté par rapport aux applications client-serveur monolithiques (avec les possibilités de juxtaposition de pages et de sites multiples au sein d’unp portail, et l’integration de WebServices applicatifs dans un espace interne), l’ensemble définit bien une architexture de système d’information, qui recouvrira rapidement tant le site externe public, que le "portail citoyen" et aussi (renforcé par l’esprit OpenData) selon les choix des élus, l’accès partiel aux informations de services de gestion interne.
(en introduction, on relira avec intéret les divers niveaux évoqués par l’Artesi).

Plusieurs axes de couverture sont à envisager :

- les informations publiées sur la collectivité (et par les agents chargé de cette communication)

- les informations destinés aux citoyens, d’origine externe (ex. : infos de voirie issues de la Comm.Comm..)

- les informations publiées sur les services externes (ex. MJC, Piscine, Scolarité, Restaurant, Ecoles de Danse...)

- les informations d’interactivité du portail citoyen (actes d’etat-civil, inscriptions Enfance par exemple, paiement en-ligne)

- les publications et consultations d’archives (par exemple, on peut considérer la publication des actes, comme intégrée à la GED, ou au site : mon opinion est que la GED doit etre immédiatement pensée comme devant s’intégrer à long terme dans le site Intranet-Extranet-Internet).

- les extraits publics des données de gestion, et bientot sans doutes les extractions S.I.G.

Ces réflexions induisent deux conséquences :
- ce projet est une brique dans l’architecture sécurisée d’un ensemble d’applicatifs Web,
(à relier donc en particulier avec les problématiques d’annuaire, voir par ailleurs) et
- l’inter-opérabilité de l’ensemble des outils logiciels du sytème d’informations est un pré-requis à prendre en compte immédiatement, surtout quand on pense aux délais de renouvellement d’un progiciel métier !

Remarque complémentaire, à contrario d’un progiciel métier, dont les données et probablement l’organisation de fonctionnement est connue et figée dans la collectivité (comme dans la plupart des collectivités), l’utilisation du Web est par essence totalement mobile, y compris dans la navigation et la recherche par les utilisateurs.

Cela signifie que la navigation dans le site, et le contenu disponible changera au cours du temps,et que la structuration arborescence si facile a contruire aujourd’hui peut fort bien se révéler complètement erronée moins de deux ans après (cela m’est arrivé !). D’ou l’importance de prévoir des possibilités de navigations alternatives (par mots-clés..) modifiables par votre administrateur webmestre interne !

 Evacuons les aspects techniques

Pour créer un site Web, nous allons faiure quelques hypothèses simplificatrices :
- la collectivité ciblée n’a pas de spécialiste en développement, meme si des informaticiens (internes ou autres, elus..) ont des notions d’HTML et de CSS, et sauront intervenir par FTP sur un serveur.

- la programmation Web (que ce soit -par ordre décroissant- en PHP, en Perl, en Python ou en Java) ne doit pas etre requise, ni pour le fonctionnement de base, ni pour la mise en place de fonctionnalités supplementaires

- "last, but not least" : par souci d’indépendance vis-à-vis des prestataires potentiels, la création du Site Internet sera obligatoirement basée sur un outil libre (et cela comprend non seulement le serveur type LAMP, mais aussi le CMS utilisé, attention au piège !
Pour plus d’informations, voyez la récente jurisprudence validant le droit d’une collectivité à choisir le logiciel support pour simplement demander la prestation de mise en place)

- l’inter-opérabilité est requise avec le reste du système d’informations, que ce soit en termes de réseau et de domaine, de serveur et d’annuaire, et de bases de données (certains CMS peuvent inter-agir nativement avec la quasi-totalité des SGBD existant, ce qui peut etre rapidement utile au moins en termes de lecture de données)

- en termes de langages (cf. cités plus haut), (pro)posons quelques idées :

  • actuellement les solutions PHP sont les plus courantes et les plus faciles à adapter
  • l’usage de Perl est sans doute plus facile pour les Admins réseau
  • ne négligeons pas la montée de Python (en particulier lié au SIG)
  • une solution réellement industrielle à long terme serait-elle uniquement java ?

Par simplicité (et parce qu’il m’arrive de modifier les sources), je privilégie actuellement PHP ! Et vous ?

 Les prestations à demander

L’approche présentée ci-après s’inscrit en faux par rapport aux prestations courantes, qui mettent trop souvent l’importance sur la graphie de la page d’accueil pour choisir le site ; or c’est sans doute la partie la plus facile à changer (par les CSS, si du moins le CMS utilisé est correctement programmé), et celle qui devra évoluer régulièrement, pour "relooker" le site.

Identifions 4 champs de prestation informatique et un champ de prestation graphique :

- l’hébergement : couvrant la disponibilité en exploitation, les sauvegardes exportées quotidiennement et les mises-à-jour de sécurité (système de base et applicatifs)

- l’installation : qui a pour but d’intégrer sur une machine (réelle ou virtuelle), le serveur Web, la configuration du CMS, l’ajout des modules spécifiques et l’adaptation de la charte graphique : présente des aspects systèmes techniques (sécurité face au hacking des pirates...)

- le remplissage (l’édition du contenu /initial/ peut généralement être conservée en interne comme support d’une form’action pour les agents editeurs de la ville)

- le design graphique : l’apparence graphique est sans doute le volet artistique le plus surfait et le moins "informatique" d’un site Internet (ou Intranet) : cela peut comporter deux volets, la conception d’une maquette graphique, et son intégration au modèle de site choisi par ailleurs, sous traités à deux prestataires distincts.

- la présentation des données, c’est-à-dire le choix des arborescences, ou plutot l’expression des divers modes de navigations (par arborescence de rubriques, par circulation directe entre articles, par recherche "plain-text" ou sur titres, et par exploration de mots clés ou encore suivi des modifications quotidiennes), à compléter eventuellement pas les modules [spécifiques ou pré-existents] fournissant un comportement particulier : formulaires de demande d’actes ou d’inscriptions, réservations et pre-paiement, géo-localisation, co-marquage service public... qui seront parfois à programmer s’ils n’existent pas dans la base du CMS choisi.

- le contenu informationnel à publier (ou à récupérer/mettre-à-jour dans le cas de l’extranet), qui relève d’une analyse informatico-organisationnelle (voir plus haut !) aura été défini en interne, en s’appuyant entre autres sur le système d’informations et la GED pré-existente.

Il est clair que ces diverses prestations ne sont pas du meme niveau d’expertise technique, et qu’un bon webmestre n’est pas forcément un graphiste créatif et encore moins un expert programmation, et surtout pas un ingénieur-système : c’est aussi un atout de croiser les prestataires, qui facilitera ultérieurement la mise en concurrence pour les adaptations et modifications que vous aurez désormais à prévoir frequement sur le site.

Dans l’exploitation, il faudra aussi distinguer les charges de mises-à-jour du système support, des versions de CMS, et de nouveaux besoins ou de modules complémentaires ; toutes prestations complémentaires à se faire proposer en complément de "la réalisation du site".

 Quelques réflexions coté finances

Deux principes sous-tendent la réflexion :

- limiter la dépense globale en se plaçant immédiatement en état de concurrence potentielle maximum (aujourd’hui et à l’avenir) pour garder toute indépendance par rapport à un prestataire
Pour cela, le choix ’a priori’ d’outils CMS totalement publics, libres et bien répandus est un gage d’économies et de liberté, mais également de qualité et de sécurité !

- raisonner en cout de possession à terme (5 à 10 ans !), car la mise en place d’un site Internet n’est que la première application de ce S.I.E (qui intègrera bientôt également du S.I.G. réparti ou distribué).

L’allotissement de la prestation entre plusieurs spécialistes a déjà été évoqué, mais cela implique tout de même de prévoir des suivis de maintenance et d’assistance à l’évolutivité (système, CMS et applications) :
- un exemple : prévoir le passage à un serveur 64bits, IPv6 et HTML5 = combien ?n

Placer une bonne part de la prestation en prise en main, form’action ou accompagnement est doublement gagnant, d’une part car cela apporte la prise en main de l’outil par vos agents, et donc valorise leur acceptation ; d’autre part, il s’agit d’un filtre redoutable pour les SSLL [1] ’amateurs’ qui n’oseront pas présenter une maitrise relative....
A l’opposé, il faudra rester extremement prudent sur le format logiciel libre (source réellement public et ouvert ?) et la possession des données (en particulier, le temps de saisie du contenu rédactionnel prendra rapidement une valorisation importante, qui pourrait être perdue en cas de changement d’outil CMS ou de prestataire), surtout dans le cas de location : l’économie apparente en exploitation initiale risque d’être perdue lors d’évolutions [2] ultérieures....

Une attention particulière sera apportée à l’examen des conditions de réalisation possible de nouvelles améliorations au site, tout au long de sa vie, car pas un seul communicant ne garde la meme communication figée ; alors, il vaut mieux encadrer d’avance les dépassements budgétaires induits...

 Quelques points annexes au choix

Plus que le choix d’un CMS (mais WordPress n’est pas un CMS complet AMHA), c’est le type d’utilisations et de navigations qui définira le produit : mais d’autres facteurs sont souvent oubliés, car on va définir une base architecturale au S.I.E (Système d’Information Extranet).

La prise en compte de la vie du système d’information extranet (maintenance d’évolution, pérennité ou unicité du prestataire -sa disparition—) conduit à privilégier à mon avis des solutions libres Open-source (voir les travaux du groupe éponyme), avec les conséquences qualitatives évidentes :
- existence d’une communauté active, avec des professionnels impliqués
- réactivité aux failles de sécurité (voir les suivis du CERTA)
- documentation et forums français utilisateurs, références
- architecture technique supportée (SGBD, masi aussi programmation..)
dont vous pouvez prendre connaissance en analysant rapidement
-> la structure de base de données, avec PhpMyAdmin ou Db4Designer
-> la documentation des interfaces de programmation
- bibliothèques, plugins et modules complémentaires (professionnels)
- en particulier la facilité de mutualiser, ou d’ajouter des objets rédactionnels nouveaux ou spécifiques
- performance technique et cache serveur (pensez au scandale de France.fr)

Un avis personnel sur le sujet : je sais que ces critères, séveres, disqualifient immediatement Joomla, et dans une moindre mesure WordPress qui n’est que un système de blog ; privilégiant PHP éliminant encore à ce jour les produits basés sur Java ou Plone/Python, ecartant egalement Typo (trop lourd au moins pour une ’petite’ collectivité et moins répandu), en l’absence de pratique d’eZpublish, il ne reste plus guère que SPIP (cocorico) et Drupal, dont la nouvelle version 8, avec des briques de Symfony2, constitue peut-etre l’archétype actuel. Reste à verifier la résistance aux modifications (en cas d’erreur lors d’une modification quelconque, comment vous, vous pouvez revenir à une version précédente sauvegardée, et vous pouvez la remettre en ligne !), car vos élus n’attendront pas, c’est l’image de la ville !

Le contexte organisationnel retenu pour les agents éditeurs induit une contrainte a priori inutile, c’est la gestion d’un annuaire des utilisateurs et de leurs droits : à moins d’etre stackanoviste de resaisie, vous viserez à terme l’intégration dans un annuaire LDAP, qui doit être adaptable en natif au CMS choisi ; lequel doit donc offrir de facon intégrée une gestion fine des droits d’edition et de consultation, par zones et/ou par rubriques.

L’architecture du CMS doit expressement permettre les modifications indépendantes, des pages de présentations (souvent appelés fonds de page, parges-types ou squelettes) et des thèmes (au sens purement graphique, c’est-à-dire CSS) d’apparence ; cela pour que votre site soit effectivement modifiable de facon souple, exemple, qu’il s’agisse de changer la dimension de l’image du bandeau ou les couleurs de polices présentant les inter-titres dans les pages.
A ce niveau, avoir une structure réellement modulaire et non-couplée, par utilisation de templates, ne mélangeant pas HTML et PHP dans les memes fichiers peut etre un avantage fort à moyen terme.
Et n’oublions pas que ce choix d’un produit premier, va entrainer formations des utilisateurs à une nouvelle interface (que ceux qui n’ont pas eu de problèmes de migration entre versions de suites bureautiques Office ou OOO se souviennent que ce choix va durer pour peut-etre toutes les applis ultérieures Intranet..).


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.

[1LL pour Logiciels Libres

[2Si seulement celles-ci sont réellement permises


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.

Article publié le 19 juin 2014, et actualisé en juin 2014 .

Répondre à cet article