LamiRene:
...
Je devrais sûrement arriver (avec un peu d'aide) à déporté le travaille de lecture des encodeurs à des CI dédiés qu'a cela, ainsi je n'aurai plus de perte de clic ou de portion de clic dû au 60 à 85 millisecondes de la boucle « loop () ». Et le besoin des broches avec interruptions disparait pour les encodeurs.
...
bonjour
si tu pars vers cette solution, il faut aussi te poser la question du protocole de mise à dispositions des infos (et lesquelles ) vers ton MCU de gestion globale.
si toujours tu veux partir sur tes 328 (DIP* ) je partirais sur de la mise à disposition par I²C
sous reserves d'erreurs , il te resterait dispo 16 pins exploitables pour de l'encodeur simple A/B (soit 8 encodeurs)
les pins 1, 2,3,7,8,9,10,20,21,22,27,28 du 328 etant "reservés" = en vrac les alims/serial/I²C/reset/QZ
le temps de boucle en polling reste extrement faible (pour de l'encodeur "manuel" , mais pas pour de l'encodeur derriere moteur) , il suffit donc simplement de mettre à jour un compteur par encodeur , compteurs lisibles par le MCU de gestion en I²C.
ce qui est largement à la portée du 328
Intuitivement , je verrais bien un "pseudo protocole" consistant à interroger regulierement/polling I²C les "modules X encodeurs" qui renverraient une reponse " à l'ouest rien de nouveau" 
ou "il y a eu du changement " avec action en consequence.
AMHA , la reflexion doit surtout etre portée sur l'organisation des "compteurs" (valeurs absolues ou pas ? , etendue, flag de changement, etc) et la discussion I²C qui doit rester la plus concise possible (= si je n'ai rien d'interessant à dire , je repond juste que je n'ai rien à dire )
- sauf à me planter les 328 en CMs (nano dispose de 2 pins de plus)