diff --git a/docs/DoxygenLayout.xml b/docs/DoxygenLayout.xml
index ad60d4c4..71d5484a 100644
--- a/docs/DoxygenLayout.xml
+++ b/docs/DoxygenLayout.xml
@@ -7,8 +7,11 @@
-
+
+
+
+
diff --git a/docs/IA.md b/docs/IA.md
new file mode 100644
index 00000000..5fe4a116
--- /dev/null
+++ b/docs/IA.md
@@ -0,0 +1,10 @@
+# IA
+
+
+For the moment we have implemented a random AI. It chooses a card and a number of boxes. It will then randomly select the selected hexagons.
+
+Thus, rules that do not impose many conditions on the selected hexagons will be favored. This is why the technology wheel and the placement of a city will be the most played cards.
+
+## Running the IA
+
+To start the IA you have to join a game with "IA" or "random" as player name.
diff --git a/docs/multithreading-network.md b/docs/multithreading-network.md
new file mode 100644
index 00000000..aabd94da
--- /dev/null
+++ b/docs/multithreading-network.md
@@ -0,0 +1,9 @@
+# Multithreading and Network
+
+## Multithreading
+
+Our game is designed to be multithreaded. On the client side, the game display runs in a separate thread from the game engine. Similarly, data reception from the network is launched in a dedicated thread. On the server side, each new client accepted launches a data reception function in a dedicated thread. When the game is ready to be launched, it is started in a dedicated thread.
+
+## Network connection
+
+For the network, we chose a TCP connection between the client and the server. This connection has the advantage of being bidirectional, which allows us greater freedom to communicate. We have associated this with a command system that allows us to exchange data in the form of text or serialized binary data. In a communication regime established between the server and the client, the dedicated thread for reception only performs data reception. The sending is done from other threads of the client or server using mutexes for reading or writing to the socket. The server can send data to a single client, all clients, or even make a blocking request to one of the clients. A system with a question, an answer, and a condition_variable allows for a request between two entities and receiving the answer, which therefore arrives in another thread. The thread responsible for data reception only performs functions with quick execution, to avoid blocking reception for an extended period of time. As a result, the server can make a request to a player and the player can make a request to the server completely simultaneously.
diff --git a/docs/rules.md b/docs/rules.md
new file mode 100644
index 00000000..f197f44c
--- /dev/null
+++ b/docs/rules.md
@@ -0,0 +1,11 @@
+# How rules are computed
+
+# The concept
+
+To play the rules, the player first selects on his window all the necessary elements to play a card. This can be the number of boxes, the path of a caravan or the position of a control pawn.
+
+Once he is done, he can click on the end of turn button. Then, the data concerning the card played is then transferred to the server thanks to a class which serves as a data structure (this class is RuleArgsStruct). The server will then launch the corresponding rules and check if the actions requested by the player are possible. if possible, then the structure will be communicated to all players who execute the map.
+
+# Display of chages
+
+Running the rule will update the map and after a few moments the client will detect this update and display the changes on the screen.
\ No newline at end of file