Transformer des problèmes récurrents d’intégration Unreal en proposition commerciale

MESH Interactive n’a pas commencé avec un business plan. Il est né de la difficulté à intégrer des systèmes Unreal Engine qui n’avaient jamais été conçus pour fonctionner ensemble.

Un framework de locomotion peut être excellent. Il en va de même pour l’interaction, l’inventaire, les armes, les véhicules ou l’IA. Le problème apparaît lorsque plusieurs produits veulent contrôler le même état du personnage, les mêmes entrées, le même comportement d’animation ou reposent sur des hypothèses réseau différentes. Un développeur peut posséder toutes les bonnes briques et malgré tout passer des mois à les faire fonctionner comme un produit unique.

Marc Thornton et Raed Abbas ont rencontré ce problème en collaborant sur la conversion multijoueur du framework Character Interaction. Leurs méthodes de travail se sont révélées complémentaires : Raed apportait une expertise plus profonde en réseau et réplication Unreal ; Marc se concentrait sur la coordination des systèmes, la réflexion produit, les opérations techniques et la couche commerciale autour du travail.

Le 8 décembre 2018, Marc a proposé d’aller au-delà du projet immédiat et de concevoir une base réutilisable plus propre. Le 11 décembre, les deux ont décidé d’en faire un projet commun à 50/50. Marc a proposé l’identité MESH Interactive deux jours plus tard et enregistré meshinteractive.com le 14 décembre.

La proposition était volontairement pragmatique.

MESH ne prétendait pas que tous les systèmes de gameplay devaient être recréés. Lorsqu’une technologie Marketplace solide existait déjà, elle pouvait être intégrée, adaptée et répliquée. Les fonctionnalités sur mesure pouvaient ensuite être construites autour des éléments réellement spécifiques.

La valeur résidait dans la couche d’intégration : faire fonctionner ces éléments de manière cohérente dans une architecture prête pour le multijoueur.

Marc s’est concentré sur la transformation de cette capacité en quelque chose qu’un studio pouvait comprendre et acheter. Il a créé le nom et l’identité, enregistré le domaine, construit le site et l’infrastructure e-mail, mis en place Discord, développé le positionnement et les éléments de licence, puis travaillé sur l’offre commerciale. Raed poursuivait les démonstrations et les systèmes spécialisés.

Les supports publics ont fini par montrer un large ensemble de domaines interconnectés : locomotion, caméras, ramassage d’objets, sauvegarde/chargement, classes de personnages, inventaire et équipement, véhicules, interaction, armes, optiques et balistique, combat, IA, loot et multijoueur coopératif ou compétitif.

Cette largeur nécessite une attribution précise. Marc et Raed n’ont pas affirmé avoir créé toutes les fonctionnalités sous-jacentes. MESH combinait des technologies Marketplace et sur mesure. La proposition concernait la base technique et le travail d’intégration nécessaires pour les faire fonctionner ensemble.

Le teaser a été lancé publiquement le 21 février 2019. La question suivante était de savoir si des studios paieraient pour cette capacité.

Une petite demande a donné lieu à un devis formel mais n’a pas abouti. Une opportunité plus importante est arrivée en mars. Le studio prospect souhaitait combiner plusieurs technologies Unreal majeures, dont Advanced Locomotion System, Survival Game Kit et Character Interaction, dans un jeu multijoueur. Un NDA a été signé et les discussions sont entrées dans une découverte détaillée couvrant caméras, comportement des personnages, inventaire, véhicules, armes, locomotion, interaction, combat au corps à corps, tir à l’arc, lobby et architecture réseau.

Marc gérait une grande partie des échanges client, besoins, cadrage commercial et périmètre, tandis que Raed se concentrait sur les questions d’ingénierie spécialisées.

La mission a révélé un problème fréquent dans la vente de solutions techniques complexes. Le client voulait légitimement la preuve que les éléments difficiles pouvaient être résolus avant de s’engager. L’équipe technique voulait tout aussi légitimement démontrer sa capacité. Des prototypes ont commencé, notamment autour d’une caméra véritablement à la première personne.

Mais la frontière entre prouver la faisabilité et commencer gratuitement l’implémentation est devenue de plus en plus floue.

Le 19 mars, les attentes sur le périmètre, le prix, les preuves et les livrables avaient suffisamment divergé pour que l’engagement s’arrête avant tout paiement ou travail de production rémunéré attesté.

Cette vente non conclue est devenue l’un des enseignements les plus utiles de MESH.

Aujourd’hui, nous poserions la limite plus tôt. Les premiers échanges doivent qualifier l’opportunité. Tout ce qui exige une architecture significative, de l’expérimentation ou des prototypes doit passer dans une phase de découverte payante avec des livrables et critères d’acceptation explicites. La production ne doit commencer qu’après avoir réduit cette incertitude de manière contrôlée.

MESH lui-même est resté un projet relativement court. L’essentiel du développement et du travail commercial s’est déroulé en 2019, la collaboration a diminué plus tard dans l’année et le domaine a été annulé en décembre.

Mais le projet a démontré plusieurs choses. Un problème d’intégration difficile et ponctuel peut révéler un besoin répétable. Une expertise d’ingénierie spécialisée peut être transformée en proposition produit plus claire. Et un excellent travail technique nécessite des limites commerciales tout aussi solides autour de la découverte.

Cette dernière leçon fait aujourd’hui partie de la manière dont Digital SHIFT aborde le logiciel sur mesure et les partenariats techniques : apprendre suffisamment avant de s’engager dans la construction, sans déguiser une ingénierie non rémunérée importante en « juste une dernière preuve ».