Le théorème CAP, ce qu'il dit vraiment

On le récite comme une règle de comptoir : « cohérence, disponibilité, tolérance aux partitions — choisis-en deux ». La formule est élégante, facile à retenir, et trompeuse presque partout où on l'invoque.

Cette formule circule de réunion en réunion comme un proverbe, citée pour clore le débat plutôt que pour l'ouvrir : « CAP, c'est deux sur trois ». Elle est fausse, et elle fait manquer ce que le théorème dit réellement.

La lettre qu'on lit mal

Le malentendu tient à une lettre : le P. On le présente comme une option, au même rang que les deux autres, comme si l'on pouvait décider de ne pas « prendre » la tolérance aux partitions. Mais une partition n'est pas une fonctionnalité qu'on active : c'est un événement qu'on subit. Dès que deux composants communiquent à travers un réseau — et tout système distribué le fait —, le lien peut se rompre, ralentir ou devenir incertain. Refuser le P reviendrait à garantir que le réseau ne tombe jamais : aucune architecture ne le tient.

La lettre remise à sa place, le théorème dit quelque chose de plus précis. La tolérance aux partitions n'est pas en jeu : elle est imposée. Ce qui se décide, c'est le comportement quand la partition survient. Là, deux conduites seulement, qui s'excluent :

• tenir la cohérence — au sens fort, la linéarisabilité : le système se comporte comme s'il n'existait qu'une seule copie, où chaque lecture voit la dernière écriture — en refusant de répondre, ou en bloquant l'écriture, tant qu'on n'est pas sûr de servir un état correct, au prix de la disponibilité ;
• tenir la disponibilité : répondre quand même, avec l'état disponible localement, au prix d'un risque de divergence, donc de la cohérence.

C'est tout le théorème : sous partition, on arbitre entre cohérence et disponibilité. Pas deux sur trois — deux conduites face à un troisième terme qu'on n'a pas choisi. Et ce choix se tranche par opération, pas en bloc ; on y revient.

Le silence du cas normal — et ce que PACELC en dit

Reste le cas le plus fréquent, qu'on oublie parce qu'il ne fait pas de bruit : l'absence de partition. Réseau intact, composants synchrones — et là, le théorème n'a presque rien à dire. Presque : même sans partition, un arbitrage subsiste entre latence et cohérence, car se coordonner pour rester cohérent prend du temps. C'est ce que formalise PACELC (Abadi, 2012) : si Partition, alors cohérence ou disponibilité ; sinon (Else), latence ou cohérence. On peut être cohérent et disponible quand tout va bien — rarement sans payer en latence.

D'où l'inutilité de l'étiquette « CP » ou « AP » prise à l'absolu : elle prétend décrire un comportement permanent, alors qu'il s'agit d'une réaction à une défaillance qui, le plus souvent, n'a pas lieu. CAP n'est pas une classification ; c'est un cadre de décision pour le jour de l'incident. La question n'est pas « ce système est-il CP ou AP ? », mais « que fait-il quand le lien se brise, et pour quelle opération ? ».

La partition n'est pas qu'une coupure réseau

« Partition » évoque un câble coupé, un datacenter isolé. L'image, trop spectaculaire, fait oublier les partitions ordinaires — celles qui surviennent chaque jour sans qu'aucun câble ne casse : un appel qui dépasse son délai, une file qui déborde, une projection de lecture en retard de quelques secondes sur l'écriture. Aucun réseau coupé, et pourtant, un instant, deux parties du système n'ont plus la même vision de l'état.

D'où un élargissement utile : pour décider une architecture, traiter comme partition toute situation où la communication ne peut plus être tenue pour assez fiable afin de préserver un comportement synchrone simple. La cause technique importe peu ; ce qui compte, c'est la perte de certitude. Au sens strict de Gilbert et Lynch, le théorème vise la partition réseau entre nœuds distincts ; mais l'arbitrage qu'elle impose — répondre avec un état incertain, ou s'en abstenir — se rejoue à l'identique dès qu'une frontière, même locale et sans câble, cesse d'être fiable. (Nuance : une projection volontairement asynchrone, en retard par conception, relève moins d'une panne que du compromis latence/cohérence — le « Else » de PACELC. On parle ici de partition au sens large : même arbitrage, pas même cause.) Sous cet angle, la partition n'est plus un cas exotique mais une réalité courante :

• un timeout répété, qui signale une perte de certitude locale plus qu'une panne ;
• une file saturée, où les messages s'accumulent sans être traités ;
• une projection en retard, qui sert une lecture en deçà de la dernière écriture ;
• un service externe indisponible ou lent à répondre ;
• un message reçu hors ordre, ou en double ;
• un état inaccessible au moment où on en a besoin.

Le point commun n'est pas la rupture du lien, rarement en cause : c'est que la réponse de l'autre n'est plus garantie — elle peut tarder, manquer, arriver deux fois ou dans le désordre. Dès qu'une opération franchit une frontière, mieux vaut le supposer d'emblée : retards, pertes, doublons, ordres imparfaits, indisponibilités, vues divergentes. Nommer ces incidents « partition » permet de leur appliquer un raisonnement déjà outillé, au lieu de les découvrir un à un.

Si la partition est à ce point ordinaire, elle ne vit pas qu'entre serveurs lointains : elle apparaît à chaque séparation de responsabilités — entre domaines, entre écriture et lecture, jusque dans un monolithe. On ne peut donc pas trancher entre cohérence et disponibilité une fois pour toutes, au niveau du système. C'est l'objet du prochain article.