diff --git a/HowtoElasticsearch.md b/HowtoElasticsearch.md
index 89ac11b9..64dd0be0 100644
--- a/HowtoElasticsearch.md
+++ b/HowtoElasticsearch.md
@@ -795,10 +795,108 @@ On peut récupérer la liste de tous les index, classés par nom :
 $ curl -s 127.0.0.1:9200/_cat/indices | sort -k 3
 green open index1 vewTWN8WRB-2V6xIgE7oQQ  1 1  2190434      0      2gb      1gb
 green open index2 k0a2yjwSS_CKKSydoVzcoQ  1 1  2164950      0    1.9gb 1020.5mb
-green open index3 rMtU36wXSNS9q9w6BDp0sA  1 1  3156725      0    2.9gb    1.4gb
+green yellow index3 rMtU36wXSNS9q9w6BDp0sA  1 1  3156725      0    2.9gb    1.4gb
 […]
 ~~~
 
+On peut limiter la liste selon la valeur de certaines colones (exemple :`health`) :
+
+~~~
+$ curl -s 127.0.0.1:9200/_cat/indices?health=yellow
+green yellow index3 rMtU36wXSNS9q9w6BDp0sA  1 1  3156725      0    2.9gb    1.4gb
+~~~
+
+### Consulter l'état des shards
+
+On peut voir si les shards sont correctement alloués (`STARTED`) ou pas.
+
+~~~
+$ curl -s 127.0.0.1:9200/_cat/shards
+index3     1 p STARTED        0    191b 10.0.0.13  node3
+index3     1 r STARTED        0    191b 10.0.0.12 node2
+index3     1 r UNASSIGNED
+~~~
+
+Ici on voit que `index3` a un shard non alloué. Pour savoir pourquoi on eput interroger l'état de l'index à propos de ses chards :
+
+~~~
+$ curl 127.0.0.1:9200/index3/_shard_stores?pretty
+{
+  "indices" : {
+    "index3" : {
+      "shards" : {
+        "1" : {
+          "stores" : [
+            {
+              "wPZvU6MUQkmhSb4YrszYeA" : {
+                "name" : "node3",
+                "ephemeral_id" : "6EK7veXhQrKAi42UB_97Zw",
+                "transport_address" : "10.0.0.13:9300",
+                "attributes" : { }
+              },
+              "allocation_id" : "RkL8f2wNS5CVL-MJYVHDaA",
+              "allocation" : "primary"
+            },
+            {
+              "yuF0yDqHTeyj7Z3rDt9HXw" : {
+                "name" : "node2",
+                "ephemeral_id" : "sIkpMVcGTyCkXx4RDd_mgA",
+                "transport_address" : "10.0.0.12:9300",
+                "attributes" : { }
+              },
+              "allocation_id" : "-piepczfSEiyTV9vN-l5MQ",
+              "allocation" : "replica"
+            }
+          ]
+        }
+      }
+    }
+  }
+}
+~~~
+
+On voir qu'il y a bien un _primary_ mais un seul _replica_.
+On peut alors interroger le cluster sur l'état des allocations :
+
+~~~
+$ curl '127.0.0.1:9200/_cluster/allocation/explain?pretty'
+~~~
+
+La sortie est en JSON et peut être assez verbeuse.
+Elle contiendra des explications a priori assez claires sur d'éventuels soucis d'allocations de shards.
+Dans cet exemple (tronqué) un shard _replica_ ne peut pas être alloué sur un nœud dont la version d'Elasticsearch n'est pas cohérente.
+
+~~~.json
+{
+  "index" : "index3",
+  "shard" : 1,
+  "primary" : false,
+  "current_state" : "unassigned",
+  "unassigned_info" : {
+    "reason" : "REPLICA_ADDED",
+    "at" : "2019-07-31T07:04:15.845Z",
+    "last_allocation_status" : "no_attempt"
+  },
+  "can_allocate" : "no",
+  "allocate_explanation" : "cannot allocate because allocation is not permitted to any of the nodes",
+  "node_allocation_decisions" : [
+    {
+      "node_id" : "--e8PpGsSKifZ5lFlDkW3A",
+      "node_name" : "node1",
+      "transport_address" : "10.0.0.11:9300",
+      "node_decision" : "no",
+      "deciders" : [
+        {
+          "decider" : "node_version",
+          "decision" : "NO",
+          "explanation" : "target node version [5.6.6] is older than the source node version [5.6.15]"
+        }
+      ]
+    }
+  ]
+}
+~~~
+
 ## FAQ
 
 ### Erreur "failed to map segment from shared object: Operation not permitted"