Depuis quelques semaines, je saute d’un blogue à Wikipedia, puis de Wikipedia à YouTube. Le changement ne tient pas seulement aux sujets. Le visiteur n’est plus limité à demander une page par HTTP et à la lire : il peut envoyer un formulaire, corriger un texte, téléverser une vidéo et faire apparaître son contenu dans le site.

Le bouton Publier cache une chaîne plus longue que sa petite taille le laisse croire. Pour un commentaire, le navigateur envoie une requête POST. Le serveur associe la demande à une session, valide les champs, transforme le texte en représentation sûre, l’écrit dans une base de données, puis invalide ou reconstruit la page affichée aux autres lecteurs. Un fil RSS peut ensuite signaler le nouveau contenu sans que chacun recharge le site au hasard.

Formulaire -> validation -> filtre antipourriel -> base de données
                                      |                |
                                      v                v
                               file de modération   page + fil RSS

Pour une vidéo, le problème grossit. Le fichier arrive par morceaux et peut dépasser la durée d’une requête Web normale. Il faut contrôler son type réel, limiter sa taille, le stocker, puis souvent produire des versions adaptées à la lecture. Si le traitement prend deux minutes, le serveur ne devrait pas garder la page ouverte pendant deux minutes : il enregistre le travail dans une file, répond « reçu » et laisse un processus séparé encoder la vidéo.

Publier n’est pas la même chose qu’afficher

Cette séparation permet aussi la modération. Un billet peut recevoir un état comme en_attente, visible, refusé ou retiré. La page publique ne lit que les éléments visibles. On garde ainsi une trace de la décision au lieu de supprimer silencieusement une ligne dès qu’un problème est signalé.

Un modèle simple pourrait ressembler à ceci :

INSERT INTO commentaires (article_id, auteur, texte, statut, cree_le)
VALUES (@article, @auteur, @texte, 'en_attente', GETDATE());

Les paramètres comptent : concaténer directement le texte d’un visiteur dans la requête ouvre la porte à l’injection SQL. L’affichage doit aussi encoder les balises pour éviter qu’un commentaire injecte du JavaScript chez les autres lecteurs. Le Web participatif augmente la valeur du site, mais il augmente en même temps la surface d’attaque.

Le pourriel suit naturellement le même chemin que les vrais participants. Une limite par adresse, un délai entre les publications, une vérification de liens et une file de quarantaine peuvent réduire le bruit. Aucun filtre n’est parfait. Il faut pouvoir libérer un bon commentaire, bloquer un compte et revenir sur une décision sans casser toute la conversation.

Le volume change aussi l’architecture. Une page préparée par dix employés grandit à un rythme connu. Une plateforme ouverte ne sait pas si dix ou dix mille vidéos arriveront demain. Il faut surveiller l’espace disque, le temps d’encodage et la taille des files, puis refuser proprement un fichier plutôt que remplir le disque du serveur.

Je ne collerais pas un profil et un bouton Téléverser sur chaque page. Une communauté doit avoir une vraie raison de contribuer, et l’équipe doit savoir qui répond aux signalements. Quand cette raison existe, je construirais la publication comme un pipeline contrôlé, pas comme un accès direct à la base. Le Web devient plus vivant précisément parce qu’on laisse entrer du contenu imprévisible; l’architecture doit être prête à l’accueillir sans lui faire confiance aveuglément.