La fonction agrégation statique des drivers Intel (pas d'agrégation supportée de base sur les Windows non serveur) semble en partie fonctionner :
 - un curl : 1Gbps (une connexion TCP ne peut donc pas passer par les deux liens)
 - deux curl : la plupart du temps 2Gbps, mais parfois 1Gbps partagé entre les deux sur la même interface (surtout quand je les lance en même temps, et pas avec quelques secondes de décalage)
 - nperf (appli ou browser), speedtest (browser) donnent la plupart du temp 1Gbps, et un peu instable, mais j'ai un test avec une moyenne à 1612Mbps.

Il y a une consommation CPU importante sur un coeur, donc c'est peut-être ça qui limite dans certains cas, mais le comportement est très étrange.

Je ne sais pas si les drivers Intel font quelque chose de particulier : l'outil configure les deux cartes avec la même MAC, il n'y a bien qu'une seule IP.
Ce qui est sûr, c'est que je peux avoir deux curl qui font l'envoi sur une connexion, et la réception sur une autre : la LB5 ne semble donc pas répondre sur l'interface ayant initié la connexion (sauf si le driver Intel a décidé de changer l'interface d'envoi en cours de connexion, ce qui serait bizarre).

Peut-être qu'il y a quelque chose autour des réponse ARP (ou des envois spontanés), soit aléatoire, soit piloté par le driver Intel.
Par exemple, la Livebox pourrait utiliser la dernière réponse ARP et donc voir régulièrement le PC "changer de port". L'agrégation fonctionnerait alors grâce au fait que les connexions TCP seraient routées vers le "port courant" au moment où elles ont été établies, même s'il change ensuite.

Thread très intéressant, dommage que je n'ai pas l'air d'être le bienvenu 

J'ai essayé de changer ce réglage à 1 comme tu dit, mais l'upload est toujours un peu dégueu... Comment tu fais pour "envoyer l'upload que sur un seul adaptateur" de manière sûre ?

Le réglage à 1, c'est pour le download.
Pour l'upload, je n'ai fait que constater deux comportements différents, qui semblent aléatoires.
Il n'est pas possible d'activer npcap sur les interfaces individuelles, donc Wireshark ne voit que l'agrégation : impossible de s'en servir pour voir ce que le driver Intel fait vraiment.

Je vais essayer d'expérimenter avec Linux, mais il n'y a peut-être pas de mode équivalent, ni de moyen de limiter l'upload à une seule interface (si c'est réellement le problème).

Techniquement si l'upload est stable quand on utilise qu'une seule interface je suppose qu'en uploadant sur une seule ça devrait fonctionner...

Ce n'est pas forcément possible (même en écrivant un driver dédié), parce qu'au moment de l'établissement d'une connexion TCP sortante (par exemple), l'OS ne sait pas quel sera son usage (majoritairement download, upload, ou les deux).

Je vois deux hypothèses qui expliqueraient le fonctionnement en download :
 - les ARP changent le port "actif", et c'est celui au moment de l'établissement de la "connexion" qui récupère le flux ensuite
 - le port ayant établi la "connexion" reçoit les paquets associés

Si c'est le premier cas, alors il est effectivement théoriquement possible d'envoyer toutes les trames sur le même port, tout en répondant aux ARP (ou en envoyant des "ARP gratuits") alternativement sur les deux ports (au en fonction de leur charge en réception).
Si c'est le second cas, alors il faut que les TCP SYN des connexions "de download" soient répartis sur les deux ports.

J'ai pu capturer les paquets sur les deux interfaces sous Windows a l'aide de pktmon.
Avec deux curl lancés avec 2s d'écart, je ne vois aucun ARP entre les deux, les SYN effectués sur les deux interfaces, et le SYN+ACK qui revient sur l'interface ayant effectué le SYN.

Mais sous Linux, avec le module bond en mode=balance-xor xmit_hash_policy=layer3+4, ça ne fonctionne pas bien du tout :
 - avec deux connexions établies en même temps, les SYN partent sur des interfaces différentes, mais les SYN+ACK peuvent être reçus sur une seule interface, ou en "croisé"
 - la plupart du temps, on reste limité à 1Gbps (réception sur une interface), et parfois on a presque 2Gbps
 - pendant les transferts, il y a des pertes de paquets sur le LAN si je fais un ping depuis une autre machine (le switch ne doit pas aimer)
Il n'y a pas de lien entre l'interface sur laquelle le SYN+ACK a été reçu, et celle qui va servir par la suite (on peut avoir la réponse initiale sur une même interface et 2Gbps par la suite, ou l'inverse).

La Livebox ne répond donc pas simplement sur le port ayant initié la connexion, c'est probablement plus compliqué.
Je ne sais pas pourquoi l’agrégation des drivers Intel sous Windows semble mieux s'en sortir, peut-être qu'un "basculement" plus lent entre les deux interfaces pose moins de problèmes.