L’exemple très simple que je donne ici, avec PHP et JavaScript, ne gère pas non plus la synchronisation des modifications (précisément parce qu’il est simple et qu’il doit le rester).

Il faut donc implémenter un système dans le logiciel qui gère les accès à la base de données, si c’est nécessaire. Car cela ne l’est pas forcément. Dans le cas d’un wiki, comme Wikipédia, il est évident qu’il faut gérer les modifications simultanées d’un article. Mais dans un forum ou un blog, par exemple ? Ce n’est généralement pas nécessaire, car la seule personne autorisée à modifier un message est celle qui a écrit ce message (hormis les modérateurs et administrateurs, mais leur intervention est gérée par un système de droits, et celle-ci prévaut sur celles des autres utilisateurs).

Bref, sans n’avoir jamais implémenté un tel système (je n’en ai jamais eu besoin), on pourrait imaginer une première requête vers la base de données avec AJAX, lorsque le champ devient éditable (événement onclick, par exemple) qui insère un verrou dans une table spéciale (table verrou : id_article, id_utilisateur, timestamp…), ou dans une colonne de la table contenant le texte (table texte : id, contenu, auteur, is_locked). On pourrait ensuite modifier la requête d’enregistrement qui, en plus de faire un UPDATE sur le texte, retirerait le verrou. Il ne resterait qu’à prévoir un “failsafe” dans le cas où le verrou n’est pas fermé au bout d’un moment (l’auteur est parti prendre un looong café sans enregistrer les modifications…), ainsi qu’un message avertissant les autres utilisateurs qu’ils ne peuvent pas modifier le texte tant qu’il est verrouillé.

Tout cela serait plutôt simple à implémenter, mais pas très élégant pour les utilisateurs qui devraient prendre leur mal en patience lorsqu’un texte est verrouillé (et l’on sait qu’avec le Web 2.0, la patience n’est pas de mise). Il faudrait alors créer un véritable système de gestion de versions, comme SVN ou Subversion, ou comme ceux de Wikipédia ou de WordPress, et s’inspirer de leur manière de gérer les accès (COMMIT) concurrents au même contenu. Mais cela est une autre affaire.

Si c’est trop complexe, on peut faire plus léger (mais aussi moins sûr), en se contentant d’avertir l’utilisateur de l’existence d’un accès concurrent, et en le laissant agir de manière appropriée. On pourrait ainsi créer un DIV spécial dans la page, et le mettre à jour avec AJAX, pour dire à l’utilisateur soit “il y a X utilisateurs en train de modifier cette page”, soit “attention le contenu de la page a changé pendant que vous écriviez” (on pourrait dans ce cas, toujours avec AJAX, surligner ou mettre en évidence d’une manière ou d’une autre ce qui a changé).

Ma conclusion est donc la suivante : la gestion des versions concurrentes du même document est un problème complexe et indépendant de la manière d’éditer les données. L’attribut contenteditable ne s’occupe que de l’édition des données. Il permet de rendre l’expérience utilisateur plus agréable, mais il est impuissant à gérer les versions concurrentes. D’ailleurs, que l’on utilise contenteditable et AJAX ou les bonnes vieilles requêtes GET/POST synchrones, cela ne change rien au problème des versions concurrentes. Donc, si le logiciel est susceptible de générer des versions concurrentes, il doit être capable de les gérer.

Je vais peut-être dire une grosse bêtise mais le problème de la concurrence d’accès (envoi quasi simultané d’un document modifié par 2 personnes distinctes) n’a-t-il pas été complètement laissé de côté ?
C’est bien de faire allusion un moment aux bases de données mais dans le cas présent et contrairement à ces dernières, si un internaute commence à éditer le contenu, aucun mécanisme de verrou me semble-t-il ne permet d’éviter qu’un autre larron ne commence de son côté à modifier le contenu.
L’exemple de Wikipédia me semble pertinent. Beaucoup de monde et des gros documents. La haine si le document que je viens de réviser pendant 3 heures est ignoré sous prétexte qu’un autre quidam a validé son édition une seconde après moi.
Désolé si une subtilité m’a échappé qui prévient ce souci.
J’imagine bien un début de solution (au moins un pis-aller). Ajouter une fonction pour gérer l’événement “Focus” qui irait interroger le serveur pour vérifier si un verrou a été positionné et le positionner justement si ce n’est déjà le cas. Gros défaut, il faut prévoir un mécanisme de “rafraîchissement” régulier pour éviter qu’un inconscient qui fermerait sa page Web SANS valider ou annuler ne bloque indéfiniment le document qu’il aurait commencé à modifier.
D’ailleurs je suis en train de penser à un autre “détail” alors que j’écris le mot “annuler”. Ce nouvel attribut “contenteditable” autorise-t-il justement l’abandon des modifications en cours ?
Je me pose une autre question. Comment les sites et outils existants gèrent cette problématique jusqu’à maintenant ? (Je viens de procéder à quelques tests rapides sur Wikipédia et le résultat est assez “surprenant”. C’est plus subtil que du verrouillage et il s’en sort globalement pas trop mal. Ce qui est certain c’est que ce n’est géré qu’au moment de la “publication”, donc en phase finale, pas avant.)

D’avance merci pour tout éclaircissement.