diff --git a/Operation.md b/Operation.md
index d86d0f6..95570d3 100644
--- a/Operation.md
+++ b/Operation.md
@@ -15,3 +15,12 @@ Ce processus se déroule en plusieurs étapes :
 **Et voilà !** Le serveur et le client sont maintenant tout les deux équipés d'une clé qui va leur permettre de communiquer de manière sécurisée.
 
 ## Communication
+
+La suite de la communication va ensuite s'effectuer de manière 100% symétrique. Les clés communes possédées par le serveur ne servent donc qu'a effectuer la négociation. Les messages sont donc systématiquement chiffrés avec la clé de session avant d'être transmis. Ils sont chacun associés à un MAC, pour Message Authentication Code, qui va permettre d'assurer l'intégrité et l'authenticité des messages. 
+
+Son fonctionnement se décline en 2 étapes:
+
+1. Avant le transfert des données, le MAC est calculé à l'aide de la clé de session et est joint au message.
+2. A réception des données, le MAC est calculé a nouveau par le destinataire de la même façon. Ils doivent donc coordonner. Si ce n'est pas le cas, cela signifie que le message a été compromis et le message est rejetée.
+
+Afin d'assurer la sécurité de la transmission, des nouvelles clés de session doivent être générées régulièrement. Ce processus consistait à simplement exécuter une nouvelle fois la négociation tout en maintenant la connexion pour l'utilisateur. Ce protocole a drastiquement changé avec la version 1.3 de TLS. Maintenant les nouvelles clés sont juste des versions dérivées des anciennes clés de session. Autrement dit, il n'y a plus besoin de transmettre de données entre le client et le serveur pour la régénération si ce n'est un message `KeyUpdate` afin de demander à l'autre partie de générer des nouvelles clés. Les 2 ont donc déjà tout les éléments nécessaires afin de générer une clé identique.
\ No newline at end of file