Je vais laisser les gros systèmes de côté. Ce qui me fait réfléchir est plus simple : une paroisse trouve maintenant assez normal de publier ses heures, son adresse et ses activités sur le Web. Je ne travaille pas sur un projet de ce genre; je le regarde comme un excellent exercice de conception sobre.

Le trajet minimal est déjà complet. Le nom de domaine possède une entrée DNS qui pointe vers un serveur. Le navigateur ouvre HTTP, demande /horaire.html, reçoit du HTML et télécharge les quelques images ou feuilles de style référencées. Si la page est statique, le serveur peut retourner le même fichier sans exécuter une base ni une session. Moins de composantes signifie moins de pannes et une réponse rapide sur une connexion téléphonique.

visiteur → DNS → serveur Web → HTML + CSS + petites images
                              ↳ aucune base requise pour l'horaire courant

Le contenu possède quand même un modèle. Une célébration n’est pas juste une phrase copiée dans trois pages :

Evenement
  titre
  dateDebut
  dateFin
  lieu
  recurrence
  statut (prévu, déplacé, annulé)
  dateDerniereVerification
  responsable

Pour un petit site, ce modèle peut rester une fiche ou un gabarit éditorial plutôt qu’une base. L’important est qu’une heure ait un propriétaire, une date de vérification et un seul endroit de référence. Le menu, la page d’accueil et le calendrier ne devraient pas contenir trois copies manuelles qui divergent.

Le HTML le plus utile reste ordinaire :

<h1>Horaire des célébrations</h1>
<p><strong>Dimanche :</strong> 9 h et 11 h</p>
<address>
  123, rue Exemple<br>
  Téléphone : 555-0123
</address>

Un vrai titre, du texte et une adresse fonctionnent sans JavaScript, se copient, s’impriment et restent lisibles par un lecteur d’écran. Une image qui contient tout l’horaire est plus difficile à mettre à jour et inaccessible si elle ne charge pas. Le contraste, la taille du texte, les liens descriptifs et une navigation au clavier servent davantage qu’une animation d’entrée.

Le poids compte encore en 2005. Une photo de 1 Mo peut prendre plusieurs minutes sur un modem. Je l’exporte à la dimension affichée, je garde le JPEG raisonnable et j’indique largeur et hauteur pour que la page ne se déplace pas pendant le chargement. Les pages importantes devraient rester utilisables si les images n’arrivent jamais.

La mise à jour est le système le plus fragile. Je définirais ce petit workflow :

1. une personne désignée reçoit les changements;
2. elle modifie une copie de prévisualisation;
3. une deuxième lecture vérifie dates, téléphone et adresse;
4. les fichiers sont publiés par FTP avec une copie de la version précédente;
5. on ouvre les pages depuis l’extérieur et teste les liens;
6. les annonces expirées apparaissent dans une liste hebdomadaire de retrait.

Le mot de passe FTP ne va pas dans le HTML ni dans un courriel général. Les fichiers du serveur sont sauvegardés, et le poste de publication garde un antivirus à jour. Si un formulaire de contact est ajouté, il doit valider la taille et les champs, limiter les abus et ne pas afficher publiquement les adresses des destinataires. Une simple adresse de courriel protégée contre le spam peut être un meilleur premier choix.

Une panne de l’hébergeur ne devrait pas faire disparaître la seule copie. Le domaine, les accès et une archive complète des fichiers doivent être récupérables par une deuxième personne, avec une courte procédure pour publier ailleurs si l’interruption dure.

Pour vérifier la valeur du site, je demande à quelqu’un de trouver l’heure de dimanche, l’adresse et un numéro de téléphone sur une machine lente, puis j’éteins les images. Si la réponse reste claire, le mécanisme fait sa job. Le Web n’a pas besoin de remplacer le bâtiment; il doit publier une information fiable avec moins de friction que le répondeur téléphonique.