Votre IA de recyclage a 1,5 mètre de retard — et la physique n'attendra pas
J'ai vu une bouteille en PET écrasée filer devant un éjecteur pneumatique à quatre mètres par seconde, intacte, et j'ai su que quelque chose était fondamentalement cassé.
Nous étions dans un centre de tri des matériaux — un MRF, dans le jargon du secteur — quelque part de bruyant et de chaud, à regarder la démonstration d'un système de tri par IA connecté au cloud. Le discours était brillant. Le tableau de bord était superbe. Le réseau de neurones pouvait identifier dix-sept types de matériaux avec une précision impressionnante sur un banc d'essai. Mais sur le tapis en fonctionnement, avec de vrais déchets circulant à une vitesse réelle, le système ne cessait de rater. Non pas parce que le modèle avait tort. Parce que la réponse arrivait trop tard.
Ce moment a cristallisé quelque chose autour duquel je tournais depuis des mois. L'industrie du recyclage n'a pas un problème de précision de l'IA. Elle a un problème de physique. Et aucun ajustement de modèle ni optimisation d'API ne le résoudra, car la contrainte n'est pas dans l'algorithme — elle est dans l'architecture.
Je suis rentré à notre bureau et j'ai fait le calcul qui se trouve désormais au cœur de nos recherches sur l'IA embarquée sur FPGA pour la récupération des matériaux. Le chiffre qui a tout changé : 1,5 mètre. C'est la distance que parcourt un morceau de matière recyclable sur un tapis roulant standard pendant le temps qu'il faut à un système d'IA cloud pour réfléchir.
Que se passe-t-il en 500 millisecondes ?
Une demi-seconde semble n'être rien. Vous clignez des yeux en environ 300 millisecondes. Mais sur un tapis roulant tournant à 3 mètres par seconde — une vitesse modeste pour les lignes de tri modernes — 500 millisecondes signifient que l'objet a parcouru un mètre et demi. À 6 mètres par seconde, vitesse que les installations à haut débit comme celles utilisant la technologie SPEEDAIR de TOMRA atteignent couramment, ce chiffre double pour atteindre 3 mètres.
Un aller-retour d'inférence IA cloud standard — capture par la caméra, encodage, transmission, mise en file d'attente, traitement par lots sur GPU, inférence, retour — prend environ 500 millisecondes. Ce n'est pas le pire des cas. C'est un cumul réaliste de chaque étape de la chaîne.
Aux vitesses de tapis industrielles, un délai d'inférence cloud de 500 ms crée un déplacement aveugle de 1,5 à 3,0 mètres — bien au-delà de la précision requise pour l'éjection pneumatique.
Le mécanisme d'éjection de ces machines est une rangée de minuscules valves pneumatiques, espacées de 12,5 à 31 millimètres, qui émettent des jets précis d'air comprimé. Elles doivent atteindre le centre de masse d'une bouteille, canette ou fragment de plastique spécifique sans perturber la matière voisine. La tolérance spatiale se mesure en millimètres. Le cloud fournit des réponses mesurées en mètres.
Je me souviens d'avoir expliqué cela à un investisseur qui ne cessait de demander pourquoi nous ne pouvions pas « simplement utiliser une API plus rapide ». J'ai sorti une serviette en papier et j'ai dessiné le tapis, la caméra, le cloud, l'éjecteur. J'ai écrit l'équation — déplacement égale vitesse multipliée par temps — et j'ai vu son visage changer. C'est l'équation la plus simple de la physique, et elle démolit toute la thèse de l'IA cloud pour le tri.
Pourquoi ne peut-on pas simplement « anticiper » ?
C'est la première objection que tout le monde soulève, et elle est raisonnable. Si le cloud met 500 millisecondes à répondre, il suffit de monter la caméra 1,5 mètre en amont et de laisser le système « anticiper », non ?
Nous avons essayé de raisonner ainsi. Mon équipe a passé deux semaines à le modéliser, et la réponse est : cela fonctionne sur un tableau blanc et s'effondre sur le sol d'une usine.
Le problème, c'est que les tapis roulants ne sont pas des instruments de précision. Ils vibrent. Les moteurs bourdonnent à des fréquences qui font dériver latéralement les plastiques légers. À des vitesses supérieures à 4 mètres par seconde, les films minces et le papier se comportent comme de minuscules profils aérodynamiques — les opérateurs appellent cela l'effet « tapis volant » — se soulevant de la surface du tapis et voltigeant de manière imprévisible. Les bouteilles en verre lourdes roulent dans les barquettes en plastique, les faisant dévier toutes deux de leur trajectoire.
Sur une distance de 1,5 mètre, ces forces stochastiques se cumulent. Un contenant léger parfaitement centré sous la caméra pourrait se retrouver deux centimètres à gauche au moment où il atteint l'éjecteur. Les algorithmes de suivi linéaire peuvent compenser une vitesse de tapis constante, mais ils ne peuvent pas prédire des collisions entre un bocal en verre et un pot de yaourt qui ne se sont pas encore produites.
Il y a aussi la contrainte physique brute. Dans les installations existantes — soit la majeure partie de l'industrie du recyclage — on ne peut pas simplement rallonger une ligne de convoyage de deux mètres. Il faudrait repenser l'agencement de l'usine, déplacer des portiques, modifier les angles d'alimentation. Le CapEx est énorme, et vous le dépensez pour accommoder un système d'IA lent plutôt que pour corriger la lenteur.
Et puis il y a l'option dont personne ne veut parler : ralentir le tapis. Si vous ne pouvez pas trier avec précision à 4 mètres par seconde, descendez à 1 mètre par seconde. Problème résolu — sauf que vous venez de réduire de 75 % la capacité de traitement de votre installation. Dans une industrie qui fonctionne avec de faibles marges à la tonne, ce n'est pas un compromis. C'est une condamnation à mort pour la rentabilité du projet.
L'ennemi que l'on ne voit pas : la gigue
La latence moyenne est déjà bien assez mauvaise. Mais le véritable tueur, c'est la gigue — la variation de cette latence d'une inférence à la suivante.
Un système cloud peut avoir une moyenne de 500 millisecondes, mais les requêtes individuelles fluctuent. L'une revient en 480 ms, la suivante en 520 ms, et de temps à autre l'une prend 600 ms parce qu'un tampon de routeur s'est rempli quelque part dans l'Ohio. Cette variation de ±50 ms crée une fenêtre d'incertitude de tir de 100 millisecondes. À 3 mètres par seconde, 100 ms représentent 300 millimètres de trajet.
Pour garantir un tir dans cette fenêtre, le système devrait émettre une rafale d'air comprimé couvrant une zone de 30 centimètres. Cela gaspille des quantités énormes d'air comprimé et éjecte tout ce qui se trouve dans cette zone — la matière ciblée et la bonne matière qui se trouve à côté. La pureté s'effondre.
J'ai eu une vive discussion avec un collègue à ce sujet. Il insistait sur le fait que l'edge cloud 5G résoudrait le problème de gigue. Je lui ai montré les chiffres : même l'edge 5G introduit 20 à 50 millisecondes de latence avec son propre profil de gigue. À 6 mètres par seconde, 20 ms représentent encore 120 millimètres de déplacement. Mieux que le cloud, mais toujours d'un ordre de grandeur trop imprécis pour des valves espacées d'un pas de 12,5 mm.
Dans le tri à haute vitesse, la latence de queue — le délai au 99e percentile — compte davantage que la latence moyenne. Si 1 % des paquets arrivent en retard, 1 % de votre matière triée est erronée.
Pour une installation traitant 50 tonnes par heure, une baisse de pureté de 1 % signifie 500 kilogrammes de contaminants par heure se glissant dans ce qui devrait être des balles propres. C'est suffisant pour rétrograder une balle de la catégorie A à la catégorie B, ou déclencher un rejet pur et simple par un acheteur. L'équation économique se défait rapidement.
Pourquoi nous avons choisi le silicium programmable
Une fois que j'ai compris que le problème était architectural — et non algorithmique — l'espace des solutions s'est considérablement rétréci. Il nous fallait une latence d'inférence inférieure à 2 millisecondes, et il fallait que ce chiffre soit déterministe. Pas « généralement sous les 2 ms ». Toujours sous les 2 ms. À chaque fois.
Cette exigence élimine les GPU, même les GPU embarqués. Un GPU local peut atteindre 15 à 50 millisecondes, ce qui est bien meilleur que le cloud, mais c'est variable. Les GPU tournent sur des systèmes d'exploitation. Les systèmes d'exploitation changent de contexte, gèrent les interruptions, journalisent les systèmes de fichiers, et décident parfois que c'est le moment idéal pour lancer une mise à jour en arrière-plan. Même Linux temps réel (PREEMPT_RT) est fondamentalement un système à temps partagé. Il ne peut pas garantir que l'inférence IA ne sera pas interrompue par un pilote réseau ou un démon SSH.
Nous nous sommes donc tournés vers les FPGA — les réseaux de portes programmables sur le terrain. Et c'est là que je dois expliquer quelque chose qu'il m'a fallu du temps pour pleinement assimiler, même avec une formation technique.
Un FPGA n'est pas un processeur. Il n'exécute pas d'instructions. On n'écrit pas de logiciel pour lui au sens traditionnel. On configure plutôt son tissu de silicium pour qu'il devienne le circuit qui implémente votre algorithme. Le réseau de neurones n'est pas un programme s'exécutant sur du matériel — il est le matériel.
Cette distinction paraît académique jusqu'à ce que l'on voie ce qu'elle signifie pour la latence. Un CPU va chercher une instruction, la décode, va chercher des données, exécute, stocke le résultat, et répète cela des milliards de fois. Un FPGA n'a pas de recherche d'instruction. Pas de compteur de programme. Les données circulent à travers un pipeline physique de portes logiques comme l'eau dans un tuyau. Dès que le premier pixel arrive du capteur de la caméra, le traitement commence. Le système n'attend pas qu'une image complète soit mise en tampon.
Le résultat : une inférence déterministe en moins de 2 millisecondes. À 3 mètres par seconde, cela représente 6 millimètres de déplacement de l'objet. À 6 mètres par seconde, 12 millimètres. Les deux se situent largement dans l'enveloppe de précision des buses d'éjection pneumatiques.
Un système de vision basé sur FPGA peut avoir le résultat de l'inférence pour le haut d'une image prêt avant même que la caméra n'ait fini de transmettre le bas de l'image.
Comment fait-on tenir un réseau de neurones sur une puce ?
Il y a eu une nuit — tardive, trop de café, le bureau désert — où je fixais les spécifications de mémoire du FPGA que nous avions choisi tout en faisant le calcul sur le nombre de poids de notre modèle. Les chiffres ne collaient pas. Notre réseau de neurones était trop volumineux pour la mémoire embarquée de la puce. Un FPGA dispose de mégaoctets de stockage interne rapide, et non des gigaoctets de VRAM que l'on trouve sur un GPU.
C'est le reproche historique fait aux FPGA pour l'IA : ils sont rapides mais petits. Et pendant un temps, j'ai cru que nous avions atteint un mur.
La percée est venue de la quantification — plus précisément, une quantification agressive combinée à une technique d'entraînement appelée entraînement conscient de la quantification, ou QAT (Quantization-Aware Training).
Voici l'idée centrale. Les réseaux de neurones sont généralement entraînés avec des nombres à virgule flottante sur 32 bits (FP32) parce que les calculs pendant l'entraînement doivent être précis. Mais une fois un modèle entraîné, ces poids sur 32 bits portent bien plus de précision que la tâche n'en requiert réellement. Distinguer une bouteille en PET d'un pot de lait en PEHD est une distinction visuelle macroscopique — forme, opacité, texture de l'étiquette. Vous n'avez pas besoin de 32 bits de précision numérique pour saisir cela.
Nous compressons nos modèles en INT8 (entiers sur 8 bits), ce qui réduit l'empreinte mémoire d'un facteur 4. Puis nous poussons plus loin vers l'INT4 (entiers sur 4 bits) pour les couches à forte densité de poids, ce qui la réduit d'un facteur 8. Nos tests internes montrent que l'INT4 offre jusqu'à 77 % de gain de performance par rapport à l'INT8 sur du matériel FPGA compatible, tout en maintenant une précision supérieure à 99 % du modèle FP32 d'origine.
La clé, c'est le QAT. Contrairement à la quantification post-entraînement grossière qui se contente de tronquer les poids en espérant que tout se passe bien, le QAT simule le bruit de quantification pendant l'entraînement. Le réseau apprend à être robuste face à une précision moindre. C'est la différence entre demander à quelqu'un de peindre avec un pinceau épais après qu'il a maîtrisé le travail au pinceau fin, et lui apprendre à peindre magnifiquement avec un pinceau épais dès le départ.
Avec des modèles quantifiés, l'intégralité du réseau de neurones tient dans la Block RAM embarquée du FPGA. Aucun accès à la mémoire externe. Aucun goulot d'étranglement DRAM. Les données circulent à des téraoctets par seconde à l'intérieur de la puce. Nous utilisons des frameworks comme FINN et hls4ml pour mapper des couches réseau spécifiques à des ressources FPGA spécifiques, en ajustant le parallélisme de chaque couche pour correspondre au débit du capteur de la caméra afin que le pipeline ne cale jamais.
Que signifie réellement « zéro système d'exploitation » ?
Nous exécutons notre chemin d'inférence critique sur bare metal. Pas de Linux. Pas de Windows. Aucun système d'exploitation sur la partie de la puce qui réfléchit et agit.
Les gens me demandent toujours si ce n'est pas extrême. Ça l'est. C'est aussi nécessaire.
Les puces FPGA que nous utilisons — les AMD Xilinx Zynq UltraScale+ — sont des systèmes hétérogènes sur une seule pièce de silicium. Elles contiennent à la fois un tissu de logique programmable et des cœurs de processeur ARM matériels. Nous répartissons la charge de travail sur trois domaines :
Le tissu FPGA gère le pipeline de vision, l'inférence du réseau de neurones et les signaux de commande des valves. Pure logique matérielle. Zéro gigue. L'unité de traitement temps réel — un ARM Cortex-R5 exécutant du C++ bare-metal — gère la configuration, les machines à états et les verrouillages de sécurité avec une latence d'interruption strictement bornée. Et une unité de traitement applicatif séparée exécutant Linux se charge des tâches non critiques : journalisation des données, service de l'interface web, gestion des mises à jour à distance.
Les chemins de réflexion et d'action sont complètement isolés du chemin de reporting. Si la partition Linux plante — et Linux plante — le FPGA continue de trier la matière à pleine vitesse sans interruption. J'ai vu cela se produire pendant les tests. Le tableau de bord s'est éteint, le flux de journaux s'est arrêté, et la ligne de tri n'a pas manqué un battement. C'est à ce moment-là que j'ai su que l'architecture était la bonne.
Pour le détail technique complet de cette architecture — le pipeline de flux de données, les schémas de quantification, le moteur de synchronisation bare-metal — consultez notre document de recherche détaillé.
Pourquoi cela compte-t-il pour l'économie circulaire ?
Laissez-moi traduire les millisecondes en argent.
Un MRF typique traitant du plastique PET avec une IA limitée par le cloud plafonne la vitesse de son tapis à environ 2 mètres par seconde pour accommoder la latence et les erreurs de suivi. Débit : environ 5 tonnes par heure et par mètre de largeur de tapis. Avec l'inférence embarquée sur FPGA à 2 ms de latence, cette vitesse de tapis peut tripler pour atteindre 6 mètres par seconde. Débit : 15 tonnes par heure. Même tapis. Même bâtiment. Même emprise au sol.
C'est une augmentation de 300 % de la capacité de traitement. Pour une installation fonctionnant en deux équipes — 16 heures — cela représente 160 tonnes supplémentaires traitées chaque jour. Avec le PET recyclé s'échangeant entre 400 et 800 dollars la tonne, les implications en termes de revenus se chiffrent en millions par an.
Mais le débit n'est que la moitié de l'histoire. La précision compte tout autant. Une éjection précise signifie moins de contaminants se glissant dans les balles propres (pureté supérieure, prix premium) et moins de matières ciblées manquées par accident et envoyées à la décharge (rendement supérieur, moins de déchets). Même une amélioration de 1 à 2 % du taux de récupération réduit significativement les revenus perdus et abaisse les frais de mise en décharge, qui augmentent à l'échelle mondiale.
Ensuite, il y a le coût opérationnel. Aucuns frais de sortie de données du cloud. Aucuns frais d'API par inférence. Aucuns coûts de bande passante pour diffuser de la vidéo haute définition vers un centre de données. Et les FPGA consomment 10 à 20 watts pour la charge d'inférence, contre 100 à 200 watts pour une configuration GPU comparable — un avantage d'efficacité d'un facteur 10 qui se cumule sur des dizaines de postes de tri fonctionnant 24 h/24 et 7 j/7.
Le passage du cloud au FPGA embarqué n'est pas une préférence technique. C'est la différence entre une installation de recyclage qui fonctionne sur le papier et une qui fonctionne à pleine vitesse.
Le fossé qui compte
On me pose régulièrement une variante de cette question : « N'avez-vous pas peur de la banalisation ? Que se passera-t-il quand NVIDIA sortira un GPU embarqué plus rapide ? »
Voici ce à quoi j'en suis arrivé à croire. À une époque où appeler une API pour classer une bouteille dans un JPEG statique est un projet de week-end, le fossé n'est pas le modèle. C'est la physique. C'est la capacité à identifier et éjecter cette bouteille se déplaçant à 6 mètres par seconde, au milieu d'un flux chaotique de canettes écrasées et de carton mouillé, avec 99 % de pureté, 24 heures sur 24, sans connexion Internet.
Cela requiert une conception conjointe matériel-logiciel — choisir le silicium FPGA, écrire le HDL, concevoir des schémas de quantification personnalisés, intégrer les pilotes de capteurs, et verrouiller l'inférence visuelle sur les impulsions de l'encodeur pour une précision d'éjection sub-millimétrique. Ce n'est pas quelque chose qu'on obtient en enveloppant une API.
Le paysage actuel de l'IA est plein d'entreprises opérant au niveau de la couche applicative, déconnectées de la réalité physique des opérations industrielles. Nous opérons à la couche physique. Nous n'entraînons pas un modèle pour le remettre ensuite. Nous concevons le circuit que le modèle devient.
L'industrie du recyclage est à un point d'inflexion. Les normes de pureté se durcissent. Les flux de déchets post-consommation deviennent plus complexes. La main-d'œuvre est rare. Tout le monde s'accorde à dire que l'IA est la réponse. Mais la conversation est restée bloquée sur quel modèle utiliser, alors que la vraie question est où et à quelle vitesse ce modèle s'exécute.
Un délai de 500 millisecondes n'est pas un inconvénient technique à optimiser pour le faire disparaître. C'est une impossibilité physique pour un procédé qui fonctionne à 3 à 6 mètres par seconde. L'équation est simple — déplacement égale vitesse multipliée par temps — et elle se moque du SLA de votre fournisseur cloud.
L'avenir de l'économie circulaire dépend d'une intelligence qui est rapide, déterministe, et située à l'endroit exact où le jet d'air rencontre la bouteille. Pas dans un centre de données. Pas dans le cloud. Sur la puce, à la périphérie, dans la milliseconde qui compte.
