La perception intelligente peut élargir une application ; elle ne rend pas une cellule automatiquement collaborative ou sûre.
Comprendre le changement.
Au 3 octobre 2026 : Universal Robots propose AI Accelerator comme plateforme matérielle et logicielle de développement. Une application finie reste à intégrer et valider ; les démonstrations ne prouvent ni autonomie générale ni sécurité de votre cellule.Ce qui existe aujourd’hui
AI Accelerator fournit une base matérielle et logicielle pour développer des fonctions IA sur des robots compatibles. Le choix et la validation d’une application restent un projet d’intégration.
Ce que cela apporte
Une perception adaptée peut réduire certaines contraintes de présentation des pièces. Son intérêt doit être comparé à une solution mécanique ou programmée plus simple.
Ce que cela peut faire perdre
L’outil, la pièce et la coactivité peuvent créer des risques même avec un bras dit collaboratif. Des exceptions fréquentes peuvent également déplacer la charge vers les opérateurs.
Ce qui se prépare
Des modèles plus polyvalents pourraient faciliter les changements de tâche. Cette perspective ne prouve pas qu’un robot généraliste sûr est disponible pour votre atelier.
Ce qui doit rester sous votre contrôle
L’intégrateur et l’entreprise définissent le périmètre, les protections et la reprise. Les utilisateurs doivent comprendre les états du système et pouvoir signaler les difficultés.
Robot programmé, robot collaboratif et robot avec IA : trois notions
Un bras peut répéter une trajectoire sans IA. Une application collaborative organise une forme de coactivité avec des personnes ; cela ne décrit pas le mécanisme qui choisit le mouvement. Une IA de perception peut, elle, proposer l’identité ou la position d’un objet à partir d’une image. Ces trois notions peuvent se rencontrer, mais aucune n’entraîne automatiquement les autres. Universal Robots présente AI Accelerator comme une base pour développer des applications utilisant l’IA sur des robots compatibles. Notre lecture commence par une tâche : prendre une pièce présentée avec des variations limitées, par exemple, plutôt que demander un assistant universel. Écrivez ce qui est déjà stable et ce qui change réellement. Si un gabarit simple résout la variation, l’IA n’est pas nécessairement le meilleur investissement. Si la perception peut réduire une préparation répétitive, il faut encore préciser l’incertitude acceptable, les exceptions et la manière dont la cellule refuse une situation qu’elle ne comprend pas.
Ce qui est livré, et ce que l’intégrateur doit encore construire
La documentation développeur relie PolyScope X à des outils NVIDIA Isaac ROS pour exploiter perception et inférence sur un module de calcul. La documentation du kit distingue également matériel, caméra et versions logicielles compatibles. C’est une infrastructure de développement, pas un contrat implicite de réussite pour votre manipulation. Demandez donc deux descriptions séparées : les éléments fournis et les résultats attendus de l’application intégrée. Dans un scénario de chargement de machine, le projet comprend aussi préhenseur, présentation de la pièce, communication avec la machine et gestion du cycle. Notre cahier des charges propose une matrice indiquant, pour chaque fonction, son responsable et sa méthode de vérification. Conservez les versions retenues et faites confirmer leur compatibilité avant tout changement. Une démonstration qui reconnaît une pièce ne prouve pas qu’elle peut être saisie correctement dans toutes les positions utiles. Le résultat commercial à acheter est une application définie, avec accompagnement et limites, plutôt qu’une accumulation de composants associés au mot IA.
La sécurité concerne toute la cellule, pas seulement le bras
L’INRS rappelle que les risques proviennent du robot, mais aussi de l’outil, de la pièce et de l’environnement de la cellule. Cette observation reste décisive lorsqu’une caméra et un modèle sont ajoutés. Notre conséquence pratique est de demander à l’intégrateur où se trouvent les fonctions de sécurité et sur quoi elles reposent, sans présumer que l’IA de perception les assure. Un outil coupant, une pièce chaude ou une charge tenue par le préhenseur ne devient pas inoffensif parce que le bras est décrit comme collaboratif. L’évaluation doit porter sur l’application réelle et ses différentes phases, y compris reprise, changement de série et entretien. Ce dossier n’explique pas comment réduire une distance de protection ni modifier un paramètre de sécurité. Il sert à préparer les bonnes questions et à distinguer la détection fonctionnelle d’un objet des mesures prévues pour protéger les personnes. Une trajectoire réussie en démonstration est une observation, pas une validation de l’ensemble du poste.
Faire apparaître les cas où la perception hésite
Prenons un exemple pédagogique de transfert de pièces non coupantes entre deux emplacements. Notre dossier préparatoire distingue pièce attendue, pièce inconnue, image indisponible et prise non confirmée. Ces états demandent des réponses explicites dans l’application ; nous ne proposons pas de les programmer ici. Le contrat doit préciser qui définit ces réponses et les valide avec les personnes compétentes. L’IA peut offrir davantage de souplesse devant certaines variations, mais une souplesse mal délimitée rend le comportement difficile à anticiper. Demandez une démonstration des exceptions pertinentes, dans un cadre sécurisé et prévu pour cela, pas seulement du cycle idéal. Conservez la liste des situations qui restent hors périmètre. Pour comparer deux solutions, regardez temps de préparation, reprises et interventions nécessaires autant que mouvement nominal. Ce sont des critères à mesurer dans le projet, pas des performances que nous attribuons au kit. Une application plus simple mais compréhensible peut mieux répondre au besoin qu’un système plus ambitieux dont personne ne sait expliquer les refus.
Former à la collaboration, sans faire de l’humain le dépanneur permanent
L’INRS accompagne les mesures techniques de formation, d’information et de familiarisation ; il souligne aussi les effets physiques et psychiques possibles de la collaboration. Notre proposition consiste à associer les utilisateurs à la description des reprises et des changements de série avant l’installation. Une personne ne doit pas découvrir après coup qu’elle passera sa journée à résoudre des exceptions que la démonstration ne montrait jamais. Précisez le droit d’interrompre le travail, la personne à contacter et le temps prévu pour apprendre. Séparez apprentissage du poste et évaluation individuelle de cadence. Une baisse du rythme pendant la prise en main ne démontre pas une résistance au changement. Le bénéfice attendu peut être la réduction d’une manutention répétitive ; il faut vérifier qu’il ne se traduit pas par une surveillance plus soutenue ou des gestes de reprise plus difficiles. Le robot change l’organisation du travail autant que son exécution. Cette question doit figurer dans le bilan, avec les retours des opérateurs et les limites observées.
Évoluer sans transformer une mise à jour en nouvelle application invisible
Les modèles et logiciels évoluent, mais le périmètre accepté doit rester traçable. Notre fiche de changement note version, raison, fonctions concernées et vérifications à refaire avec l’intégrateur. La documentation actuelle d’AI Accelerator contient des contraintes de compatibilité : elle illustre pourquoi « installer la dernière version » n’est pas une politique suffisante pour une cellule. Nous ne recommandons aucun changement de version particulier sans étude de votre installation. Pour l’avenir, une perception plus riche pourrait faciliter certains changements de production ; ce potentiel ne rend pas disponible aujourd’hui un robot capable de comprendre toutes les consignes d’un atelier. Distinguez chaque démonstration, prototype et application livrée dans les échanges commerciaux. Enfin, prévoyez assistance, disponibilité des compétences et fonctionnement prévu en cas d’indisponibilité du système. Le retour sur investissement doit intégrer cette continuité. Nous n’avons réalisé aucun test de robot ni évaluation de sécurité : l’objectif est de rendre l’achat et ses conséquences humaines suffisamment précis pour être discutés avant de modifier le poste.
| Situation | Apport possible | Contrôle à conserver |
|---|---|---|
| Pièce orientée différemment | Perception de position | Périmètre et prise validés |
| Personne proche du bras | Collaboration organisée | Évaluation de toute la cellule |
| Nouvelle version logicielle | Fonctions éventuellement enrichies | Compatibilité et vérifications de changement |
Les pièges à éviter
- Confondre cobot et sécurité automatique.
- Acheter une démonstration comme une application universelle.
- Oublier le travail humain de reprise des exceptions.
À vérifier avant de choisir
- Décrire une tâche et ses variations autorisées.
- Séparer kit développeur et application intégrée.
- Faire évaluer l’ensemble robot, outil, pièce et environnement.
- Préparer formation, reprises et gestion des versions.
L’IA robotique est utile quand son périmètre et ses refus sont aussi compréhensibles que ses réussites.
Sources & documentation
- Universal Robots — AI Accelerator, produit et intégration
- Universal Robots — AI Accelerator, documentation développeurs
- Universal Robots — Documentation et compatibilités AI Accelerator
- INRS — Identifier les risques d’une application robotique collaborative
- INRS — Réussir l’intégration des robots collaboratifs en entreprise
Sources consultées le 3 octobre 2026. Les caractéristiques et disponibilités dépendent des versions et références. Les méthodes proposées constituent des repères éditoriaux ; elles ne remplacent pas les notices ni les conseils professionnels adaptés à votre situation.
Les effets de l’IA dépassent cet univers. Découvrez comment ils se prolongent dans un autre domaine du réseau MOC.
Site public du réseau.
