AR4SITE

Une réservation est une ouverture prévue dans un élément de construction, un mur ou une dalle, pour laisser passer les réseaux techniques : conduits électriques, tuyaux de plomberie, gaines de ventilation. Elle doit être placée avec une grande précision. Si elle est mal positionnée, les réseaux ne s'intègrent plus correctement dans la structure, et l'erreur se paie en reprises sur l'ouvrage.

L'idée d'AR4SITE est de donner au chef de chantier un outil direct : poser l'iPad face au mur, voir la maquette numérique du projet superposée au bâtiment réel, et contrôler sur place que chaque réservation est bien alignée et bien positionnée.

J'étais sur le projet dès son lancement, en binôme avec un autre alternant de ma promotion. Avant d'écrire une ligne de code, nous avons passé beaucoup de temps en recherche : quels outils sont utilisés pour ce type d'application, que permet le modèle d'iPad dont nous disposions, et ses caractéristiques suffisent-elles pour tenir la promesse faite au client ?

Nous avons donc étudié le matériel, et en particulier le capteur LiDAR : comment il se comporte, et dans quelles conditions il est le plus fiable. Les documentations et les études que nous avons trouvées situent sa plage optimale entre 1 m et 1,50 m, avec une précision qui commence à se dégrader à partir de 4,50 m.

Ces chiffres restaient théoriques, et nous devions garantir une précision au client. Dans la documentation d'Apple, nous avons trouvé un exemple de code pour RoomPlan, une application qui modélise une pièce en 3D en la scannant avec l'iPad, puis l'exporte au format USDZ. Cet export est devenu notre outil de vérification.

Pour choisir la technologie, nous avons chacun développé une preuve de concept : moi en Swift sous Xcode avec ARKit, le framework de réalité augmentée d'Apple, mon binôme en C# sous Unity avec ARFoundation. L'idée était de comparer les avantages et les limites de chaque approche sur un cas réel : importer une maquette, puis la poser dans la pièce.

Côté données, il fallait aussi savoir manipuler les formats du bâtiment : l'IFC, le format d'échange des maquettes BIM exportées depuis Revit, et l'OBJ, plus simple à afficher en 3D. J'ai identifié et intégré les bibliothèques nécessaires, et utilisé Blender pour préparer les modèles.

Les deux preuves de concept ont buté sur le même problème : une fois recalée dans le réel, la maquette n'avait pas du tout les bonnes proportions. J'ai essayé d'ajouter un curseur pour augmenter ou réduire l'échelle, mais en testant, je me suis aperçu qu'il se bloquait à partir de x10. À ce stade du projet, aucune solution n'avait encore été trouvée : c'était le point à résoudre en priorité.

Côté Swift, je connaissais un peu le langage et Xcode, mais la réalité augmentée était un autre monde. La documentation d'Apple est de bonne qualité, mais elle n'est pas simple quand on débute sur le sujet.

Après les preuves de concept, nous avons fait une pause pour centraliser toutes nos recherches et nous recentrer sur les attentes du client. C'est à ce moment que nous avons modélisé l'architecture technique et l'architecture fonctionnelle de l'application, puis conçu ses maquettes dans Figma.

Les maquettes ont tout remis en question. En testant l'usage sur chantier, nous avons conclu que l'iPad serait tenu en mode portrait, et non en paysage, parce qu'il est trop lourd. Or, tenu à deux mains, une tablette a des zones faciles à atteindre avec les pouces, sur les bords, et une grande zone centrale tout simplement inaccessible.

Nous avons donc réorganisé toute l'interface pour que les menus, les boutons et tout ce qu'il faut sélectionner soient à portée de pouce : les modes de mesure à gauche, la barre d'outils à droite, le centre de l'écran laissé à la vue en réalité augmentée. Avant de passer au vrai développement, nous avons aussi produit le diagramme de classes de l'application, pour pouvoir développer à plusieurs sur une base claire.

Présent dès le lancement, j'ai pu influencer la façon de travailler. J'ai mis en place un tableau Trello pour structurer les tâches : des colonnes pour chaque étape du flux (à faire, en cours, terminé), des étiquettes pour prioriser, et des cartes détaillées pour chaque tâche. Le tableau a évolué au fil du projet, en fonction des besoins et des retours de l'équipe.

Pour certains aspects plus fins, j'ai complété Trello par un tableau des tâches dans Excel : chaque fonctionnalité y est découpée, assignée à une personne, priorisée et estimée en temps. Enfin, toutes nos recherches et nos preuves de concept étaient rangées dans un dossier projet partagé avec le client, pour qu'il suive l'avancement et la veille au même endroit que nous.