diff --git a/notes/CONTRIBUTING.md b/notes/CONTRIBUTING.md
index c1f9531845e04648c4748571aef0d8bbea4c287d..36e028fc17c770ef068454daabd1da7537b1755f 100644
--- a/notes/CONTRIBUTING.md
+++ b/notes/CONTRIBUTING.md
@@ -194,7 +194,7 @@ Lorsqu'une authentification est réussie, on crée une session et on l'associe 
 
 La gestion des sessions et de la distribution de cookies est gérée par passport, et est décrite dans `app.ts`.
 
-![auth](../assets/auth.png "Processus d'authentification proposé")
+![auth](./auth.png "Processus d'authentification proposé")
 
 ### Vérification des droits
 
@@ -206,7 +206,7 @@ Il semble intéressant de proposer pour Sigma une structure plus souple que Fran
 
 L'idée est aussi d'explorer ce qu'on peut faire pour opérer une cascade de privilèges et éviter les super-admins de Frankiz. Dans cette logique, on peut définir un graphe évolutif qui définit les interactions entre groupes et établit des relations de visibilités, d'appartenance et d'administrations. Cela permettrait de définir de façon plus intelligente les droits d'un utilisateur de façon presque graphique, voir :
 
-![auth](../assets/graphDroits.png "Graphe de droits")
+![auth](./graphDroits.png "Graphe de droits")
 
 ## Panneau d'administration ("adminview")
 
diff --git a/assets/LDAPGroup.png b/notes/LDAPGroup.png
similarity index 100%
rename from assets/LDAPGroup.png
rename to notes/LDAPGroup.png
diff --git a/assets/LDAPUseCase.PNG b/notes/LDAPUseCase.PNG
similarity index 100%
rename from assets/LDAPUseCase.PNG
rename to notes/LDAPUseCase.PNG
diff --git a/assets/LDAPUser.png b/notes/LDAPUser.png
similarity index 100%
rename from assets/LDAPUser.png
rename to notes/LDAPUser.png
diff --git a/assets/LDAP_API.png b/notes/LDAP_API.png
similarity index 100%
rename from assets/LDAP_API.png
rename to notes/LDAP_API.png
diff --git a/assets/auth.png b/notes/auth.png
similarity index 100%
rename from assets/auth.png
rename to notes/auth.png
diff --git a/assets/grapheDroits.jpg b/notes/grapheDroits.jpg
similarity index 100%
rename from assets/grapheDroits.jpg
rename to notes/grapheDroits.jpg
diff --git a/notes/hist_ldap.md b/notes/hist_ldap.md
index 52c0f8bbbc8bbb8c937216b428f08e3ecf1e4ce6..e61672e7b72aa06e9c5e13340aa57c29e0b9a06c 100644
--- a/notes/hist_ldap.md
+++ b/notes/hist_ldap.md
@@ -12,11 +12,11 @@ Le BR2017 a mené un gros travail de réorganisation du LDAP donc beaucoup d'inf
 
 Le LDAP a été significativement enrichi depuis Frankiz, puisqu'il contient la majeure partie des données utilisateurs et groupes de sigma. Les champs parent et child permettent aux resolvers afférents de faire descendre les admins et remonter les membres, mais n'a pas d'influence à l'intérieur de l'API LDAP.
 
-![newLDAPgr](../assets/LDAPGroup.png "Structure pour les groupes sur le LDAP")
+![newLDAPgr](./LDAPGroup.png "Structure pour les groupes sur le LDAP")
 
-![newLDAPus](../assets/LDAPUser.png "Structure pour les utilisateurs sur le LDAP")
+![newLDAPus](./LDAPUser.png "Structure pour les utilisateurs sur le LDAP")
 
-![newLDAPuc](../assets/LDAPUseCase.png "Exemples d'emplois du LDAP")
+![newLDAPuc](./LDAPUseCase.png "Exemples d'emplois du LDAP")
 
 #### Configuration
 
@@ -32,7 +32,7 @@ Cette API est voulue comme la plus simple et la plus minimaliste possible ; en e
 
 Cette API, bien que relativement naïve, doit être capable de garder la syn,chronisation entre les deux arbres du LDAP et ainsi que les problèmes de récursion posées par le choix de la structure en admin descendant et membres montant.
 
-![LDAPAPI](../assets/LDAP_API_.png "Etat courant de l'API LDAP")
+![LDAPAPI](./LDAP_API_.png "Etat courant de l'API LDAP")
 
 Le détail de chaque fonction est disponible dans la documentation JSDOC : ([`User`](../doc/LDAP.User.html) et [`Group`](../doc/LDAP.Group.html)).