Un robot imprimé en 3D devient beaucoup moins « réparable » si son flanc entier sort d’une imprimante comme une seule pièce. Une fissure près d’un support moteur peut alors imposer de relancer plusieurs heures de plastique pour remplacer une zone qui ne pèse presque rien.
MillieBot, le robot domestique développé par Dream Cloud, prend aujourd’hui le problème par l’autre bout. Son corps est décrit comme entièrement imprimé en 3D et découpé en composants indépendants, chacun pouvant être imprimé, assemblé et remplacé séparément.2 Le projet publie aussi, selon sa documentation, un assemblage FreeCAD éditable destiné à permettre la modification des panneaux, supports et points de fixation.2
C’est une décision mécanique plus intéressante que le discours sur son assistant vocal. Un modèle d’IA peut être remplacé par une API différente en quelques lignes ; une coque mal découpée peut condamner chaque réparation à recommencer le robot depuis le plateau de l’imprimante.
Il faut toutefois séparer ce que le projet décrit de ce qu’un constructeur extérieur peut déjà auditer. Au 23 août 2026, les pages officielles annoncent fichiers imprimables, code source et assemblage FreeCAD, mais le site public ne fournit pas de lien visible vers un dépôt GitHub ou une archive de ces fichiers. Les recherches publiques n’ont pas permis à IRZ de retrouver un dépôt officiel correspondant.12 L’ouverture est donc une promesse explicite du projet, pas encore une chaîne de reproduction que nous avons pu vérifier de bout en bout.
Découper la panne
La modularité est souvent vendue comme un mot abstrait. Pour une pièce imprimée, elle peut se mesurer avec une question beaucoup plus simple : quelle quantité de matière faut-il jeter lorsqu’un seul point casse ?
Dream Cloud affirme que le corps de MillieBot est divisé en éléments pouvant être remplacés indépendamment.2 Cela réduit théoriquement trois coûts à la fois : la matière, le temps machine et le risque de réimpression.
Une grosse coque concentre ces trois risques. Plus la durée d’impression augmente, plus une erreur tardive devient coûteuse. Une buse qui se bouche, un décollement, une géométrie mal tolérancée ou simplement un trou déplacé de deux millimètres peuvent rendre inutilisable une pièce presque terminée. Avec plusieurs modules, l’échec reste local.
Le brief de veille parlait de « gros prints de 30+ heures ». Cette valeur n’apparaît dans aucune source primaire publique retrouvée par IRZ. Nous ne la reprenons donc pas. Le principe reste valide sans chiffre spectaculaire : diviser un grand volume imprimé en sous-ensembles réduit l’étendue d’une erreur, même lorsque le temps exact varie selon machine, buse, hauteur de couche et matériau.
Les interfaces comptent
Découper une coque ne suffit pas. Les nouvelles frontières deviennent des interfaces mécaniques qu’il faut dessiner.
Chaque séparation ajoute des vis, clips, inserts, jeux, plans d’appui ou passages de câble. Une pièce remplaçable n’est utile que si elle peut être retirée sans démonter la moitié du robot et si la nouvelle impression revient à la même position.
FreeCAD prend alors une importance très concrète. Dream Cloud dit fournir le modèle d’assemblage complet et éditable, afin qu’un constructeur puisse voir comment les composants s’emboîtent et modifier une partie sans repartir de zéro.2 Dans un projet qui vise la réparation, le fichier paramétrique vaut davantage qu’un simple STL, puisqu’il conserve à la fois les dimensions, les relations entre pièces et une partie de l’intention de construction.
La promesse va assez loin. La page officielle explique que les utilisateurs devraient pouvoir redessiner panneaux, supports, capteurs, roues ou accessoires tout en gardant la compatibilité avec le reste de la plateforme.2 Si les fichiers annoncés deviennent réellement accessibles et versionnés, cette structure permettrait à une amélioration communautaire de porter sur une zone précise au lieu de créer un fork mécanique entier.
C’est la différence entre « voici le modèle de mon robot » et « voici la frontière sur laquelle vous pouvez travailler ».
Électronique ordinaire
La mécanique modulaire fonctionne mieux lorsque l’intérieur suit la même logique. MillieBot s’appuie justement sur des composants relativement ordinaires : mini-PC, Arduino Nano Every, LiDAR, caméra de profondeur, moteurs DC, batterie LiFePO₄ 12 V et routeur Wi-Fi de voyage.2
Le logiciel robotique repose sur ROS 2 Humble, Nav2 et SLAM Toolbox pour la communication, la navigation et la cartographie.2567 L’interface de contrôle utilise Flutter, tandis que le cœur logiciel est annoncé principalement en Python.2
L’intérêt n’est pas que chacune de ces pièces soit parfaite. Il vient du fait qu’un moteur, un ordinateur ou un capteur standard peut être remplacé sans devoir convaincre un fabricant de vendre un module propriétaire introuvable.
Dream Cloud insiste d’ailleurs sur cette idée dans sa présentation Kickstarter : moteurs, capteurs, caméras et ordinateurs doivent pouvoir évoluer au fil du temps plutôt que figer le robot comme un appareil scellé.3
Ouvert, jusqu’où ?
Le mot « open source » est le point qui mérite le plus de prudence.
Les pages de MillieBot déclarent que le code, le matériel, le modèle FreeCAD et les fichiers d’impression sont ouverts.12 Elles expliquent également que l’application de visage et l’application de contrôle sont modifiables.1
Mais une licence ouverte ne se vérifie pas dans un paragraphe marketing. Il faut pouvoir télécharger les sources, retrouver leur historique, connaître la licence exacte, reconstruire le logiciel ou le matériel correspondant et comprendre quelles parties du produit restent dépendantes d’un service externe.
Sur ce dernier point, MillieBot utilise par exemple l’API Realtime d’OpenAI pour les conversations vocales.12 Une couche robotique ouverte peut parfaitement coexister avec une fonction majeure dépendante d’un service propriétaire ; cette frontière mérite simplement d’être documentée avec la même précision que le reste du système.
Plus gênant aujourd’hui, les pages officielles que nous avons vérifiées ne donnent pas de chemin public évident vers les fichiers annoncés. L’architecture décrite reste évaluable, alors que la promesse la plus importante échappe encore à un test indépendant : télécharger une pièce, la modifier, l’imprimer et la remonter sur un robot réel.
Le bon test
MillieBot est actuellement lié à une campagne Kickstarter que Dream Cloud présente comme le passage d’un prototype fonctionnel vers la production.34 Cette formulation impose de ne pas traiter les caractéristiques annoncées comme celles d’un produit industriel déjà stabilisé.
La bonne question n’est donc pas de savoir si son assistant vocal est amusant. Elle est plus prosaïque : quand un support fissure, combien de pièces faut-il démonter, combien de plastique faut-il réimprimer et est-ce qu’un tiers possède réellement les fichiers nécessaires pour le faire sans permission du fabricant ?
Le découpage modulaire apporte une réponse crédible à la première moitié. Il transforme une réparation en problème local et donne à la communauté des frontières mécaniques sur lesquelles intervenir.
La seconde moitié reste à prouver publiquement. Un robot réparable n’est pas seulement un robot composé de petites pièces. C’est un robot dont les interfaces, les fichiers et les droits suivent la pièce lorsqu’elle sort de l’usine.
À condition que MillieBot publie effectivement tout ce qu’il annonce, sa meilleure idée ne sera peut-être pas son IA. Le projet aura surtout rapproché la taille d’une panne de celle de la pièce qui a réellement cassé.