Je prends le parti du edge sur ce point — à une condition. Il faut séparer votre IA en deux sortes : celle qui "surveille la route" et celle qui "lit l'avenir".

La surveillance de la route ne peut pas attendre une seule milliseconde. La lecture de l'avenir peut prendre une heure et personne ne meurt. Cette ligne est exactement là où le edge et le cloud se séparent. Ces deux dernières années, j'ai vu des entrepôts brûler de l'argent des deux côtés : tout balancer dans le cloud, puis regarder toute la ligne de tri s'arrêter dès que le réseau tousse ; ou acheter un serveur GPU le premier jour pour faire tourner un modèle de reporting qui n'a besoin de tourner qu'une fois par jour.

Où déployer l'inférence se résume à trois forces qui s'opposent : latence, bande passante et coût. Selon celle à laquelle un cas d'usage est le plus sensible, on sait où l'inférence doit vivre.

Tout ce qui se compte en millisecondes appartient au edge

Commençons par les surveillants de la route : inspection visuelle, évitement d'obstacles des AMR, pick-and-place robotisé. Le point commun est une boucle fermée mesurée en millisecondes. Une ligne de tri fait passer bien plus d'une centaine de colis par minute ; un carton reste dans le champ de la caméra l'espace d'un clin d'oeil, et le résultat de la reconnaissance doit revenir en dizaines de millisecondes. Un aller-retour vers le cloud prend facilement des centaines de millisecondes — le temps que la réponse arrive, le carton a dépassé le point de dérivation et le bras pousseur n'a plus rien à viser.

Il y a ensuite la facture de bande passante. Une seule caméra de vision qui diffuse des images brutes en continu génère des dizaines de gigaoctets par jour. Multipliez par quelques stations et vos coûts mensuels de liaison montante cessent d'être une erreur d'arrondi. Et les réseaux d'entrepôt ne ressemblent en rien aux réseaux de bureau : zones mortes de Wi-Fi, signal bloqué par les rayonnages métalliques, chariots élévateurs qui sectionnent des câbles au quotidien. Miser l'inférence temps réel sur cette chaîne, c'est confier la disponibilité de votre ligne au hasard.

J'ai vu le contre-exemple chez un 3PL à Ontario, en Californie, l'année dernière : ses caméras de codes-barres faisaient la reconnaissance dans le cloud. Un après-midi, le réseau s'est mis à sauter et toute la ligne est retombée sur des rescans manuels. Ce n'était qu'un remplacement de point d'accès pour maintenance : quatre heures avec un débit en baisse de près d'un tiers. Le patron m'a dit ensuite, avec une totale sincérité, que chaque dollar économisé sur les serveurs était parti directement en heures supplémentaires.

L'évitement d'obstacles des AMR est encore plus extrême. Le véhicule avance, une personne surgit devant lui, et l'inférence fusionnée lidar plus vision doit se terminer localement et émettre un ordre de freinage en dizaines de millisecondes. Si cette décision attendait le cloud, le véhicule serait déjà passé à travers la personne. C'est pourquoi tous les fabricants sérieux d'AMR exécutent leurs modèles d'évitement à bord — ce n'est pas une préférence technologique, c'est de la physique.

La règle pour cette catégorie tient en une ligne : si le résultat de l'inférence pilote directement une action physique, il tourne au edge. Et "la ligne continue de tourner quand le réseau meurt" entre dans les critères d'acceptation.

Caméra d'inspection visuelle scannant des colis sur une ligne de tri

Ce qui peut attendre coûte moins cher dans le cloud

L'autre catégorie, ce sont les lecteurs d'avenir : prévision de la demande, suggestions de réapprovisionnement, calculs de stock de sécurité, rapports mensuels d'exploitation. Ces modèles tournent une fois et leurs réponses restent valables un jour ou une semaine — quelques minutes de retard ne changent rien. Le vrai avantage du cloud ici n'est pas le calcul bon marché ; c'est qu'on n'a pas du tout besoin de posséder du calcul. Pas de machines à acheter, pas de chaleur à gérer, pas d'appels à 2 h du matin pour une machine morte.

Le deuxième avantage du cloud, c'est l'entraînement. L'entraînement dévore des données historiques, et l'historique de l'entrepôt vit déjà dans le cloud : la base de données du WMS, l'historique des commandes, les registres de main-d'oeuvre. Entraîner et itérer là-haut est l'ajustement naturel. L'appareil edge n'a qu'un seul travail : télécharger le modèle entraîné, exécuter l'inférence et récupérer les nouvelles versions depuis le cloud selon un calendrier.

L'architecture hybride que je vois fonctionner sur le terrain — et celle que je confierais à tout entrepôt petit ou moyen comme modèle de départ — est la suivante : le edge fait l'inférence temps réel avec mise en cache locale pour tourner en autonome quand le réseau tombe ; le cloud fait l'entraînement, la distribution des modèles et l'analytique globale. Mettez la division du travail par écrit et ne laissez aucun des deux côtés s'emparer du travail de l'autre. Déployez les mises à jour de modèles par étapes : la nouvelle version sur une station d'abord, une semaine de fonctionnement propre, puis à l'échelle de la flotte. Ne faites jamais une "mise à jour de tout l'entrepôt en un clic" — quand ça casse, tout l'entrepôt casse ensemble.

Et faites un test d'acceptation physique : le jour du lancement, débranchez le câble réseau et regardez ce qui se passe. Si la ligne s'arrête, l'architecture est de la décoration, aussi belles qu'aient été les diapos du fournisseur.

Petits entrepôts : oubliez le serveur GPU, commencez par un PC industriel

Maintenant l'argent. Les gens entendent "inférence IA" et s'imaginent un rack de serveurs GPU coûtant des dizaines de milliers de dollars. Je vais dire quelque chose d'impopulaire : neuf entrepôts sur dix n'en ont pas besoin.

Une seule station d'inspection visuelle tourne confortablement sur un appareil edge de la classe du Jetson Orin Nano de NVIDIA — la version 8 Go sortie en 2023, des dizaines de watts de consommation, tient dans une armoire électrique. Un PC industriel équipé d'un GPU, dans les quelques milliers de dollars, peut desservir deux ou trois stations. Commencez là : prouvez le ROI sur une ou deux stations — réduisez le taux de ratés des re-contrôles manuels, ou éliminez les arrêts de ralentissement sur la ligne de tri. Une fois que les comptes sont bons, parlez alors d'étendre les stations, puis des serveurs.

Un détail d'environnement constamment oublié : la poussière et la chaleur. Les entrepôts atteignent des températures élevées en été et la poussière s'infiltre partout ; du matériel grand public jeté dans cet environnement ne survivra pas à une saison de pointe. Pour choisir le matériel edge, large plage de température de fonctionnement, conception sans ventilateur et résistance à la poussière sont des exigences dures — n'achetez pas sur les seules spécifications de calcul. C'est une autre raison pour laquelle je recommande de commencer par un PC industriel : il est construit pour exactement cet environnement.

Pour qui sont vraiment les serveurs GPU ? Les opérations qui font tourner des dizaines de stations en même temps, ou les équipes qui entraînent leurs propres modèles. Si votre entrepôt n'en est pas encore là, en acheter un, c'est payer la facture d'électricité d'une salle des machines — et financer la commission du vendeur.

Mon verdict est simple : séparez d'abord vos cas d'usage en surveillants de la route et lecteurs d'avenir — edge pour les premiers, cloud pour les seconds. Commencez le matériel par un seul PC industriel, prouvez une station, puis étendez. La prochaine fois qu'un vendeur d'IA vous fait sa présentation, posez trois questions : où tourne l'inférence, la ligne s'arrête-t-elle quand le réseau meurt, et à quelle fréquence les modèles sont-ils mis à jour ? S'ils ne peuvent pas répondre à ces trois-là, vous pouvez fermer le deck de présentation.

Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.