Bonjour,
J'ai failli demander de l'aide tout à l'heure, mais j'ai réussi à trouver une solution à mon problème, donc j'en fait profiter ceux qui seraient tentés par l'aventure 8-) .

Utilisant Fedora depuis quelques années, je l'ai installé au travail et à la maison, en double boot avec Windows 7. Bien qu'allergique à Windows, je suis contraint de l'utiliser pour certains powerpoints (Libreoffice déforme les figures), pour les formulaires pdf (ils font planter Adobe Reader sous wine) et pour le traitement des photos au format raw (les logiciels que j'ai testé sous linux étaient clairement en retrait) :-? . Avant d'utiliser Fedora, j'ai commencé par Ubuntu, que je trouve plus simple et dont la documentation est très bien faite, mais j'ai besoin d'être familiarisé avec Centos qui pilote plusieurs appareils scientifiques que j'administre 😐 . Rassurez-vous le but n'est pas ici de troller, mais juste de me présenter.

Comme vous vous en doutez, passer d'un système à l'autre est une opération longue, d'où l'intérêt d'avoir un disque SSD et d'y mettre les deux systèmes d'exploitation. Toutefois je ne suis pas Crésus et je viens d'acheter un SSD de seulement 250 Go, insuffisant pour stocker toutes mes données, qui sont donc sur l'ancien HDD de 500 Go. Mais ne serait-il pas possible d'utiliser le SSD comme cache pour accélérer le HDD ? Quel partitionnement choisir ? Comment transférer les données du HDD vers le SSD ? Je vais essayer de répondre à ces questions dans ce tutoriel et de donner les solutions aux problèmes qui peuvent se poser. Prenez une bière et c'est parti :pint: .

But :
  • Passer un système double boot sur SSD
  • Accélérer le disque à plateaux par l'utilisation de lvm-cache sur le SSD
Sommaire:
I) Déplacement de Windows
II) Déplacement de Linux
III) Optimisation du HDD
IV) Problèmes lors du reboot
V) Benchmarks

EDIT : But du tutoriel et fractionnement par parties
I) Déplacement de Windows
Dans cette première partie, on va commencer par migrer l'intégralité de Windows sur le SSD.

1) Activation de l'AHCI
L'AHCI est nécessaire pour activer la technologie TRIM qui améliore les performances du SSD. Par défaut, il n'est pas activé dans le bios et windows ne démarrera plus si on le change sans précautions :idea: . A noter que ma machine datant de 2008, elle ne dispose ni de l'UEFI ni de disques GPT, mais au contraire d'un BIOS et de disques MBR.

J'ai donc suivi ce tutoriel : http://www.tplpc.com/faq/passer-de-ide-ahci-sans-reinstaller-windows-7-02240.html .
Il suffit de donner la valeur 0 aux clés suivantes de la base de registre. 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pciide = 0
On peut ensuite
  • éteindre l'ordinateur
  • débrancher le câble d'alimentation
  • brancher le SSD sur le premier port sata
  • redémarrer l'ordinateur
  • modifier dans le bios ide --> ahci
  • régler l'ancien disque en tant que premier périphérique de démarrage
Une fois sous windows, il détecte le ssd et nous demande de redémarrer à nouveau. Dans la foulée, on va régler un certain nombre de paramètres pour améliorer l'efficacité du ssd sous windows avec TweakSSD http://www.clubic.com/disque-dur-memoire/disques-durs-ssd/article-448256-6-optimiser-ssd.html .

2) Copie des données Windows
Pour ce faire, j'ai utilisé Macrium Reflect http://www.macrium.com/reflectfree.aspx qui présente l'avantage de pouvoir redimensionner les partitions tout en les copiant. J'ai donc copié trois partitions vers le SSD : la partition Microsoft Reserved, la partition Windows et la partition boot. Pour rappel, je n'ai pas de partition efi puisque je dispose d'un bios d'ancienne génération.

On a donc la répartition suivante sur le SSD :
sda1 : 128 Mo, Microsoft Reserved
sda2 : 100 Go, Windows
sda3 : 500 Mo, Boot
libre : 149 Go
II) Déplacement de Linux
Dans cette deuxième partie du tutoriel, nous allons mettre le cœur du système linux sur le SSD.

1) Partitionnement
Il est maintenant possible de régler dans le bios le SSD comme premier périphérique de démarrage et d'utiliser un live CD Fedora 23 pour réorganiser les partitions. Un outil simple à utiliser est gparted. 
# dnf install -y gparted
On va créer deux partitions sur sda :
sda4 : 150 Go, extended --> c'est le nombre maximum de partitions primaires avec un disque MBR.
sda5 : 150 Go, lvm2 --> j'ai choisi de la mettre dans une partition étendue au cas où j'ai besoin un jour pour un autre usage d'une partition supplémentaire.

Il faut ensuite désactiver la partition lvm sur sdb : 
# swapoff /dev/fedora/swap
Puis clic droit / désactiver dans gparted.

On va supprimer les partitions windows sur l'ancien disque, à savoir sdb1 (Microsoft Reserved) et sdb2 (Windows), ainsi que sdb3 (boot) :hammer: . Il ne reste donc que sdb4 qui contient les partitions linux en lvm, si vous avez fait une installation de fedora par défaut.
sdb1 : inexistant
sdb2 : inexistant
sdb3 : inexistant
sdb4 : lvm avec root, home et swap

A ma connaissance, gparted ne permet pas de modifier la numérotation des partitions, et je ne trouve pas logique de commencer par 4 :-x . On va donc déplacer l'ensemble de la partition au début du disque puis créer à droite une petite partition de 10 Go que l'on supprimera par la suite après avoir changé la numérotation grâce à fdisk https://journalxtra.com/fr/linux/how-to-reorder-linux-drive-partition-numbers/ . 
# fdisk /dev/sdb
p --> liste les partitions
x --> extra fonctionnalités - experts
f  --> fixer l'ordre des partitions
p --> vérifie
d --> 2 --> supprimer la partition de 10 Go
w --> sauver
Il est maintenant possible de retourner dans gparted et d'agrandir sdb1 pour qu'elle occupe tout le disque.

2) Préparation du système de fichier root
On va utiliser LVM qui permet entre autre d'agrandir à chaud un système de fichier et d'avoir une partition répartie sur plusieurs disques. Le principe en est le suivant : une partition lvm représente un Physical Volume (PV). Un ou plusieurs PV forment un Volume Group (VG) qui contient un ou plusieurs Logical Volume (LV), qui lui même contient le système de fichier (ext4, xfs,...). J'avoue, ce n'est pas simple :roll: . Plus d'informations sur http://www.unixarena.com/2013/08/linux-lvm-volume-creation-operation.html . Pour voir l'état actuel : 
# pvs
# vgs --> dans mon cas le VG s'appelle fedora
# lvs
On peut maintenant préparer l'emplacement pour root sur le SSD : 
# pvcreate /dev/sda5 --> on rend disponible le PV
# vgextend fedora /dev/sda5 --> on agrandit le VG fedora
3) Copie de root
On commence par copier les fichiers puis on redimensionne l'espace alloué. L'option --resisefs de lvresize permet de redimensionner à la fois le LV et le système de fichier ext4 qui se trouve dedans. On notera qu'il est nécessaire de convertir en puissance de 2 (1024) la taille à allouer. 
# lvconvert -m 1 /dev/fedora/root /dev/sda5 --> création d'un miroir
# lvconvert -m 0 /dev/fedora/root /dev/sdb1 --> suppression de l'original
# lvresize --resizefs -L 79.16G /dev/fedora/root --> = 85/(1.024^3)
Si vous préférez ne pas utiliser lvm pour root, commencez par créer une partition sda6 en ext4 avec gparted puis copiez le contenu http://www.linuxjournal.com/content/copy-your-linux-install-different-partition-or-drive . 
# mkdir /mnt/old
# mkdir /mnt/new
# mount /dev/fedora/root /mnt/old
# mount /dev/sda6 /mnt/new
# cp -afv /mnt/old/* /mnt/new/ --> ne pas oublier l'étoile après old
# umount /mnt/old
# umount /mnt/new
# lvremove /dev/fedora/root --> suppression des données
C'est tout pour ce soir. Bonne nuit.

A suivre :
III) Optimisation du HDD
IV) Problèmes lors du reboot
V) Benchmarks
III) Optimisation du HDD
Après avoir déplacé la partition root, il est maintenant temps de s'attaquer aux répertoires home et swap.

1) Défragmentation des données
Pour mémoire, après les commandes précédentes, le disque dur sdb ne contient qu'une seule partition lvm avec uniquement le home et le swap. Windows et la partition racine de fedora sont maintenant sur le disque SSD 8-) .

Par contre, le lvm n'utilise qu'une partie de la partition. Il faut donc l'agrandir : 
# pvresize
Afin de voir la répartition physique des fichiers sur la partition, on utilise pvdisplay : http://famille-michon.fr/journalgeek/2011/08/01/defragmentation-lvm/ . 
# pvdisplay --maps /dev/sdb1
On constate avant tout qu'une partie des Physical Extends (PE) est libre. En effet, les LV n'occupent pas la totalité de l'espace. On remarque également que les fichiers ne sont pas forcément répartis linéairement, et qu'il peut y avoir des espaces entre eux. Les fichiers eux-même sont très peu fragmentés, mais la mauvaise répartition des PE va entrainer des ralentissements de lecture pour deux fichiers sensés être proches.

Nous allons dans un premier temps déplacer le swap en début de disque, c'est à dire à l'extérieur des plateaux, là où la vitesse de lecture est la plus élevée. Cette commande permet de faire de la place en début de disque en déplaçant les fichiers vers un espace libre, puis de mettre le swap à la place. 
# pvmove /dev/sdb1:0-1908 /dev/sdb1:117324-119233 --alloc anywhere
# pvmove /dev/sdb1:100000-101908 /dev/sdb1:0-1908 --alloc anywhere --> déplacement du swap
On fait de même avec tous les fragments de fichiers pour les défragmenter, quitte à effectuer l'opération en plusieurs fois, selon la place libre. Dans mon cas, il m'a fallu une dizaine de déplacements pour arriver à une seule zone pour le répertoire home.

A la fin de l'opération, pvdisplay donne le nombre de PE non attribués, que l'on va utiliser pour agrandir le répertoire home, avec le signe + devant : 
# lvresize --resizefs --extends +12736 /dev/fedora/home /dev/sdb1
2) Mise en cache du répertoire home sur le SSD
Le répertoire home étant prêt, il est possible d'accélérer les fichier les plus fréquemment accédés en les stockant sur le SSD : http://blog-vpodzime.rhcloud.com/?p=45 . LVM-cache est préféré à DM-cache, car ce dernier est moins flexible et nécessite d’exécuter un fichier au démarrage de l'ordinateur pour avoir l’accélération writeback. D'après http://man7.org/linux/man-pages/man7/lvmcache.7.html , l'algorithme utilisé par défaut par lvm-cache pour choisir les fichiers à accélérer (cache policy) est smq (stochastic multiqueue, http://everything.explained.today/Dm-cache/), qui semble performant.

Au préalable, on vérifie que la partition sda5 du SSD est bien contiguë. Si ce n'est pas le cas, on utilise pvmove comme précédemment. 
# pvdisplay --maps /dev/sda5
L'activation du cache SSD se fait en une seule commande. Le mode writeback augmente la rapidité. La taille de 59.5 GiB correspond à 64 GB / (1.024^3) auxquels on a retiré 0.1 GiB pour le stockage des métadonnées du cache. 
# lvcreate --type cache --cachemode writeback -L 59.5G -n ssd_cache /dev/fedora/home /dev/sda5
On vérifie que le cache est bien activé 
# lvs
LV   VG     Attr       LSize   Pool        Origin       Data%    Meta%    Move Log Cpy%Sync Convert
home fedora Cwi-aoC--- 458,30g [ssd_cache] [home_corig] 12,72    23,67    0,00            
root fedora -wi-ao----  79,49g                                                                 
swap fedora -wi-ao----   7,46g
Pour suspendre et reprendre le cache: 
# lvconvert --splitcache fedora/home --> suspendre
# lvconvert --cache --cachemode writeback --cache-pool fedora/ssd_cache fedora/home --> reprendre
Pour supprimer le cache : 
# lvconvert --uncache /dev/fedora/home
IV) Problèmes lors du reboot
Toutes les partitions étant prêtes, il semble possible de quitter le live DVD Fedora où nous sommes depuis la partie II. Il reste toutefois quelques problèmes à régler. 😐

Pour toute cette partie, nous allons effectuer un chroot, c'est à dire que nous allons travailler sur les fichiers du disque, tout en démarrant avec le live DVD. 
# mount /dev/fedora/root /mnt
# mount /dev/sda3 /mnt/boot
# mount --bind /dev /mnt/dev
# mount -t proc /proc /mnt/proc
# mount --bind /run /mnt/run
# mount -t sysfs /sys /mnt/sys
# chroot /mnt
1) Fichier /etc/fstab
Les partitions ayant changé, il est nécessaire de vérifier ce fichier pour pouvoir démarrer. Les noms /dev/mapper doivent refléter les noms des systèmes de fichier choisis pour root, home et swap. Voici le mien pour exemple : 
/dev/mapper/fedora-root /                       ext4    defaults        1 1
UUID=1902a9cc-3ba8-40d8-9b4a-60e74951d155 /boot ext4    defaults        1 2
/dev/mapper/fedora-home /home                   ext4    defaults        1 2
/dev/mapper/fedora-swap swap                    swap    defaults        0 0
L'UUID de /boot (/dev/sda3) est obtenu avec la commande 
# blkid /dev/sda3
2) Fichier /etc/default/grub
Voici un fichier qui fonctionne : 
GRUB_DEFAULT=0
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="Fedora"
GRUB_CMDLINE_LINUX="SYSFONT=latarcyrheb-sun16 KEYTABLE=fr LANG=fr_FR.UTF-8"
GRUB_CMDLINE_LINUX_DEFAULT="rhgb quiet"
Il est inutile de rajouter
GRUB_PRELOAD_MODULES="lvm"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rd.driver.blacklist=nouveau"
LVM est en effet nativement géré par le kernel et le driver nouveau pour les cartes graphiques nvidia est déjà blacklisté dans le fichier /lib/modprobe.d/blacklist-nouveau.conf

3) Grub2
Il est nécessaire de reconstruire le gestionnaire de démarrage. Je rappelle que je ne dispose pas de l'UEFI, ce qui changerait les ordres à utiliser (https://fedoraproject.org/wiki/GRUB_2#Create_a_GRUB_2_configuration). L'option --recheck permet de relire la table de partitions et de recréer le fichier /boot/grub/device.map. 
# grub2-mkconfig -o /boot/grub2/grub.cfg
# grub2-install --recheck /dev/sda
A ce stade, windows devrait pouvoir démarrer sans problème et linux devrait s'arrêter avec une erreur :-x 
Reached target Paths
Warning: /dev/mapper/fedora-root does not exist
Dracut
4) Initramfs
L'erreur ci-dessus provient du fait que la partition lvm contenant root a été déplacée. Il est donc nécessaire de reconstruire le fichier /boot/initramfs. A ce sujet, voir http://wiki.networksecuritytoolkit.org/nstwiki/index.php/HowTo_Change_The_LVM_Volume_Group_Name_That_Includes_The_Root_Partition#Step_4:_Rebuild_The_Kernel_initramfs_File

:idea: mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r) ne fonctionnera pas. En effet, $(uname -r) renvoie le kernel du Live DVD, plus ancien que les kernels disponibles sur le SSD, ce qui causera l'erreur 
Reached target Encrypted Volumes
Warning: /dev/mapper/fedora-home does not exist
Emergency mode
Il faut donc commencer par repérer le kernel le plus récent dont on dispose puis on peut construire initramfs à partir de celui-ci. 
# ls /lib/modprobe.d/
4.4.7-300.fc23.x86_64  4.4.8-300.fc23.x86_64  4.4.9-300.fc23.x86_64 4.4.9-300.fc23.x86_64
# mkinitrd -f -v /boot/initramfs-4.4.9-300.fc23.x86_64.img 4.4.9-300.fc23.x86_64
Enfin, pour sortir du chroot, on suit l'ordre inverse. 
# exit
# umount /mnt/sys
# umount /mnt/run
# umount /mnt/proc
# umount /mnt/dev
# umount /mnt/boot
# umount /mnt
Voilà, normalement tout devrait fonctionner correctement. On peut donc redémarrer pour profiter du SSD, du home accéléré et faire des tests de vitesse. 8-) .
Pour les benchmarks, ça attendra mardi. Bon week-end à tous. N'hésitez pas à commenter.

La suite de ce tutoriel se trouve là : http://forums.fedora-fr.org/viewtopic.php?pid=562861#p562861
Je lirai plus tard le tout. C'est pas mal à première vu.

Si tu utilise ponctuellement windows tu n'as pas pensé à la virtualisation. Avec kvm?
Salut VINDICATORs et merci de ta réponse.

Oui, j'y ai pensé. J'avais essayé il y a quelques temps sous virtualbox mais c'était horriblement lent avec le HDD et mes 4 Go de mémoire. Avec le SSD et 8 Go, ça se tente à nouveau. Reste que mon proc (Core 2 Quad Q8200) semble ne pas avoir des instructions VT-X très performantes.

A+
Bel effort, problème traité assez récurrent, comme VINDICATOR je lirai, il me semble "qu'à première vue ..." que quelques raccourcis sont possibles : En temps réellement consacré, cela t'as pris combien de temps machine ?
# dd -> img ou iso et gparted (sécurité du raw) auraient probablement été plus court en temps machine et moins riche en commandes?
Salut Antbel,
Au total ça m'a pris plus d'une semaine, le temps de chercher les solutions à chaque problème, d'autant plus que j'ai commencé par dm-cache à la place de lvm-cache, et donc que j'avais supprimé les partitions lvm.

Oui, on peut sûrement faire plus court, je suis preneur. Par contre, je n'ai pas trouvé de sujet qui traite de la totalité du problème.

Quant à dd, il y a toujours le risque de ne pas avoir la bonne taille pour la partition de destination. D'autant plus que sur un ssd, les partitions doivent être positionnées à partir du 2048eme secteur et non du 63eme comme sur les HDD, avec une taille de secteur différente.

A+
Belle erreur expérience :-P (pour ceux qui ne comprennent pas c'est qu'ils n'ont pas lus la signature de GuL).
@ philippe_PMA : LOL !

Une question à laquelle je n'ai pas trouvé de réponse : comment faire pour accélérer plusieurs logical volumes par le cache SSD ? J'ai lu une ou deux références aux thin layers de lvm, mais je n'en sais pas plus. Si quelqu'un a déjà pratiqué, je suis preneur.
Bonjour à tous,
Je vais finalement avoir besoin de votre aide : les benchmarks se sont mal passé, et je ne peux même plus démarrer sur un live cd fedora 🙁 . Je m'explique.

J'ai commencé par utiliser fio (http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark), installé par dnf: 
# dnf install -y fio
# fio --name=benchmark --filename=/dev/mapper/fedora-root --direct=1 --ioengine=libaio --bs=4k --size=128M --numjobs=32 --group_reporting --rw=read
L'option --filename a vraisemblablement corrompu root qui est définitivement perdu. Soit. :-? Heureusement home est intact. Je démarre donc avec un live cd fedora et je réinitialise root par un 
mkfs.ext4 /dev/mapper/fedora-root
En continuant mes tests avec fio, je m'aperçois que le HDD non caché (/mnt/temp, LV créé pour l'occasion) et le SDD (/mnt/root) donnent le même résultat en terme de rapidité (avec l'option directory à la place de fiename !). Comment ça se fait ? :-o 
# fio --name=benchmark --directory=/mnt/root --direct=1 --ioengine=libaio --bs=4k --size=128M --numjobs=32 --group_reporting --rw=read
# fio --name=benchmark --directory=/mnt/temp --direct=1 --ioengine=libaio --bs=4k --size=128M --numjobs=32 --group_reporting --rw=read
J'ai donc essayé hdparm 
# dnf install -y hdparm
# hdparm -Tt /dev/mapper/fedora-root --> ~200 Mo/s pour le SSD en sata 2
# hdparm -Tt /dev/mapper/fedora-test --> ~100 Mo/s pour le HDD
Là où ça se gâte, c'est que j'ai voulu refaire la même manip avec le cache SSD activé 
# lvconvert --cache --cache-pool fedora/ssd_cache fedora/test
# hdparm -Tt /dev/mapper/fedora-test --> freeze
Le redémarrage sur un live fedora est impossible, même avec l'option single dans la commande du grub : il bloque sur le montage de la lvm. Avec un live ubuntu (qui utilise beaucoup moins lvm), je peux démarrer, mais le cache lvm semble bloqué. Voici le résultat de lvremove 
# lvremove --force /dev/fedora/test
/usr/sbin/cache_check: execvp failed: No such file or directory
Check of pool fedora/ssd_cache failed (Status:2). Manual repair required!
Failed to active cache locally fedora/test.
Failed to uncache fedora/test.
Après ajout du dépot universe et des thin-provisioning-tools 
# apt-get update ; apt-get install thin-provisioning-tools
# lvremove --force /dev/fedora/test
134313 blocks must still be flushed
132506 blocks must still be flushed
...
freeze
Au secours !!! :idea:
Salut antbel,
Merci pour le lien, j'y ai appris le raid 1 sous lvm. Par contre as-tu une idée pour mon problème ? Comment supprimer un cache défectueux ?
A+
GuL wrote:Comment supprimer un cache défectueux ?
J'ai finalement réussi à m'en sortir avec un live CD ubuntu, vu qu'il était impossible de booter avec le live CD fedora, à cause du lvm endommagé. J'ai donc déplacé toutes les données récupérables vers un autre disque dur et reformaté les partitions lvm sda5 et sdb1 :-?

Avant de réinstaller les données, j'ai fait à nouveau quelques tests avec fio afin de conclure ce tutoriel, qui se trouvent dans le message ci-dessous.
V) Benchmarks
Pour conclure ce tutoriel, voici quelques tests effectués avec fio https://www.linux.com/learn/inspecting-disk-io-performance-fio . Je néglige les options directory et filename, qui ne m'ont apporté que des ennuis et je lance la commande suivante depuis la partition à tester, 
# fio --name=benchmark --ioengine=libaio --iodepth=8 --direct=1 --size=128M --numjobs=8 --runtime=10 --group_reporting --rw=write
Je crée donc
  • 8 fichiers --> numjobs=8
  • de 128 M --> size=128M soit 1 Go au total
  • auxquels j’accède 8 fois simultanément --> iodepth=8
  • de manière asynchrone --> ioengine=libaio
  • sans passer par la mémoire --> direct=1
  • pour une durée maximale de 10s --> runtime=10
  • en regroupant les résultats --> group_reporting
  • en accès écriture, lecture, écriture aléatoire, lecture aléatoire --> rw=write, read, randwrite, randread
On obtient les résultats suivants. A noter que ma carte mère est en SATA 2 c'est à dire avec une vitesse maximum de 300 MB/s
SSD : write 235 MB/s, read 235 MB/s, randwrite 203 MB/s, randread 163 MB/s, latence 1.5 ms
HDD + cache SSD : write 217 MB/s, read 234 MB/s, randwrite 200 MB/s, randread 167 MB/s, latence 1.4 ms
HDD : write 62 MB/S, read 55 MB/s, randwrite 1.4 MB/s, randread 1.0 MB/s, latence 248 ms

Les résultats avec le cache SSD s'améliorent à chaque répétition de la commande, surtout dans le cas du test d'écriture qui était le premier réalisé. Un optimum a été obtenu après 7 fois. L'optimum était atteint beaucoup plus rapidement pour les autres tests, mais le cache n'a toutefois pas été vidé au préalable. Une fois les données en cache, les résultats sont très proches du SSD. 8-)

Grâce au SSD et au cache accélérant home, il m'est maintenant possible de passer de linux à windows en une minute. Afin d'aller encore plus vite, j'envisage d'installer une machine virtuelle KVM avec VGA passthrough permettant d'utiliser opencl et cuda sur la machine invitée https://www.pugetsystems.com/labs/articles/Multiheaded-NVIDIA-Gaming-using-Ubuntu-14-04-KVM-585/ . Cependant, mon processeur intel Core 2 Quad Q8200 ne dispose pas des instructions VT-X et encore moins VT-D, ce qui est clairement un point limitant.

J'espère que ce tutoriel vous a intéressé. N'hésitez pas à faire des commentaires et à me poser vos questions. J'essayerai d'y répondre. 🙂
A bientôt
GuL