La cohérence forte présente, dans un premier temps, l'approche la plus intuitive pour une application collaborative dans le cloud.
Prenons l'approche de chercher à répliquer un processus d'édition local d'un document. Formalisons dans un premier temps ce qu'on attend d'une application d'édition de document local.

\begin{figure}[!h]
    \centering
    \resizebox{!}{.4\columnwidth}{
        \input{images/local1.latex}
    }
    \caption{Bob edit un document localement}
    \label{local_1}
\end{figure}

On voit sur la figure \ref{local_1} que Bob émet une requête à son interface utilisateur. À partir de là le clavier partage l'information au système jusqu'à l'application d'édition. En fonction du traitement de cette information, si elle est acceptée par l'application d'édition, alors elle affiche un document modifié en accord avec la saisie de Bob à l'écran. Ce qui donne un feedback à Bob concernant son action initiale.
Dans notre modélisation, nous séparons bien les actions de l'utilisateur sur ses interfaces (l'écran et le clavier) des interactions au sein du système.

Dans un cas d'usage courant, une application d'édition local ne présente pas de problèmes liés à la présence de plusieurs éditeurs en simultanés. Il y a en effet une seule interface homme-machine, c'est-à-dire de façon pragmatique un unique écran et clavier.

Imaginons ainsi un cas où Alice et Bob souhaitent éditer ensemble un même document. Si on voulait simplement appliquer le fonctionnement local que nous venons de décrire à cette nouvelle problématique. Il conviendrait de simplement rajouter un IHM à Alice. Ainsi il y a toujours une seule application d'édition collaborative sur lequel viennent se connecter cette fois-ci deux interfaces (comme visible dans la figure \ref{local_2}).

\begin{figure}[!h]
\begin{multicols}{2}
    
        \centering
        \resizebox{!}{.7\columnwidth}{
            \input{images/local2.latex}
        }
        \caption{Alice et Bob éditent un document localement}
        \label{local_2}
        
        \columnbreak

        \centering
        \resizebox{!}{.8\columnwidth}{
            \input{images/local2fail.latex}
        }
        \caption{Alice et Bob éditent un document localement de manière concurente}
        \label{local_2_fail}
    \end{multicols}
\end{figure}       


Nous avons à présents deux acteurs qui éditent et lise le document, et un autre qui s'occupe de stocker et de synchroniser le document entre ces deux acteurs.

La limite liée à cette approche réside dans le fait que les communications entre Alice et l'application et Bob et l'application ne peuvent pas être garentits comme équitables. En effet, Alice et Bob peuvent très bien se retrouver déconnectés de manière non prévisible et asynchrone. Ou bien avoir des temps de transmissions de leurs informations qui diffèrent. Le caractère non-deterministe des ces erreurs peut résulter en des incohérences dans l'ordre d'arrivé des informations soumises par Alice et Bob. Ce qui peut a terme créer des incohérences dans le document final.

C'est néanmoins une problèmatique qui peut être assimilée à de la gestion de la concurrence entre processus. C'est en effet un domaine qui est étudié depuis l'apparition des premiers processeurs multi-coeur. Une approche que nous pouvons donc prendre à la programmation concurente serait de résoudre ce problème en venant utliser des techniques de synchronisation de processus. C'est-à-dire en utilisant des mécanismes de synchronisation tel que des verrous dans notre application. On peut par exemple utiliser des sémaphores pour gérer les accès concurrents à la mémoire partagée. Ce qui resulterais en l'execution suivante:

\begin{figure}[!h]
    \centering
    \resizebox{!}{.7\columnwidth}{
        \input{images/serialized.latex}
    }
    \caption{Alice et Bob éditent un document localement avec des vérous}
    \label{serialized}
\end{figure}

On voit sur la figure \ref{serialized} que les actions d'Alice et Bob sont sérialisées. C'est-à-dire que les actions d'Alice et Bob sont exécutées l'une après l'autre. Ce qui permet d'éviter les problèmes de concurrence entre les deux acteurs. Cependant, cette approche est très limitée. En effet, elle ne permet pas de profiter des avantages de l'édition collaborative. En effet, cela signifie que l'un des deux acteurs doit attendre que l'autre ait fini d'éditer le document pour pouvoir à son tour l'éditer. Ce qui rabaisse les performance de l'application à la latence de l'acteur le plus lent.

En revenons dans notre contexte initial qui est une applicationn d'édition collaborative nous souhaitons pouvoir gérér un grand nombre d'utilisateur en simultanés. Ainsi la probabilité d'avoir une expérience dégradé pour l'ensemble des utilisateur croit avec le nombre d'utilisateur. Pour pallier à ce problème l'approche qui peut être adopté est d'exclure les utilisateurs possèdant des connections trop limités avec le serveur.

C'est néanmoins la seule approche qui nous permet d'obtenir une cohérence absolue autant dans la prise en compte des opérations d'écritures des acteurs que dans le traitement de leurs lectures.

Selon Perrin on se placerait dans une approche qui relèverait de la cohérence séquentielle.

\subsection{Cohérence séquentielle}

% blbla sur la cohérence séquentielle de manière très théorique et fondamentale



\paragraph{Validité}

Dans une application d'édition collaborative on s'attend à ce que toutes les entrées des utilisateurs soient prises en compte. Il nous parait en effet inacceptable que des saisies disparaisses de manière aléatoire durant l'exécution.

Ce principe nous permet d'introduire une première propriété utilisée par Perrin pour définir et classer les différents critères de cohérence qu'est la validité.

La validité peut ainsi être résumé comme la propriété qui permet d'assurer que toutes les saisies réalisées, et seulement elles, soient prises en compte dans l'exécution du système.

Ceci se traduit par l'affichage d'un retour quant à la saisie de bob sur son application. Lui signifiant que son interaction avec l'application à bien était prise en compte, et n'est donc pas passée à la trappe. Elle n'implique néanmoins aucune notion d'ordre dans les saisies, ce qui signifie que les saisies peuvent être réagencées durant l'exécution.

\paragraph{Convergence}

Une autre attente d'une application d'édition collaborative est en quelque sorte sont determinisme sur une durée infinie. On s'attend en effet, une fois toutes les éditions terminés, que le document soit identique pour tous les acteurs. C'est-à-dire que peut importe l'ordre dans lequel les saisies ont été réalisées, le document final doit être identique pour tous les noeuds.

C'est ce que Perrin appelle la convergence qu'il définit plus formellement comment étant la propriété qui assure que si un nombre finit d'ecriture et infini de lecture sont réaliséés, alors tous les noeuds finissent par avoir la même valeur.

\paragraph{Localité D'état}

La dernière propriétée du model de Perrin est la localité d'état.

Elle consiste en le fait que chaque acteur doivent garder une vision local cohérente du système. Par exemple, comme illustrée dans la Figure \ref{local_state}, au fur et à mesure des éditions de Bob, sa vue local va évoluer en conséquence, mais si il recoit à un moment donné une édition d'Alice qui est antérieur à une de ses éditions, alors il doit privilégier sa propre édition. C'est-à-dire que sa vue local doit être cohérente avec son historique d'édition quitte à diverger de la vue local d'Alice.

\begin{figure}[!h]
    \caption{Localité d'état}
    \label{local_state}
\end{figure}