Deux moteurs. Un seul craft. Pourquoi Consulting et Tech Factory vivent sous le même toit.

L'écart que nous voyions revenir.

Au cours de nos années à l'intérieur de cabinets plus grands et côté client, le même motif revenait sans cesse. Une équipe stratégie livrait un modèle opératoire cible élégant. Un intégrateur de systèmes construisait quelque chose contre une interprétation de ce modèle. Quand les deux livrables se retrouvaient en environnement de production, la logique d'origine de la transformation avait été silencieusement négociée à la baisse, et personne dans la salle ne pouvait dire précisément à quel moment la négociation avait eu lieu.

L'échec inverse était tout aussi courant. Une équipe d'ingénierie compétente livrait une plateforme qui fonctionnait, avec du code propre et une cadence de release respectable, mais le résultat business que la plateforme devait permettre n'arrivait pas. On avait laissé à l'équipe une centaine de micro-décisions à prendre qui étaient en réalité des décisions business, en supposant que quelqu'un en amont les avait tranchées. Personne ne l'avait fait.

Quand nous nous sommes assis pour construire B One, la question fondatrice était simple. Si ces deux échecs sont les plus coûteux dans la transformation d'entreprise, quel type de cabinet se tient là où les échecs se produisent plutôt que d'un seul côté de la ligne. La réponse sur laquelle nous avons convergé, c'est une maison avec deux moteurs, chacun sérieux à ses propres conditions, et une discipline opératoire qui leur permet de partager des dossiers sans perdre l'intégrité de l'un ni de l'autre.

Comment les deux moteurs se connectent.

Le moteur Consulting porte les piliers sur lesquels nos clients nous mobilisent généralement en premier : strategy and vision, transformation and organisation, performance and value, AI-augmented enterprise. Le moteur Tech Factory porte les piliers de build : data et AI engineering, agents et automation, modern applications, plateforme et travail de fiabilité. Chacun a sa propre direction, ses propres rituels, son propre rythme de delivery.

Quand un dossier ne vit que dans un seul moteur, il y reste. Une mission de conseil autour d'une refonte organisationnelle tourne comme une mission de conseil, avec l'équipe, les méthodes et les livrables qui fonctionnent pour ce type de question. Un build Tech Factory tourne comme un build, avec l'équipe, les revues d'architecture et les standards d'opérabilité qui décident si la plateforme survit à sa première année.

Quand un dossier appelle les deux, la connexion est structurée plutôt qu'improvisée. Un Consulting partner siège sur le modèle opératoire et les choix business qui façonnent la cible. Un Tech Factory partner siège sur ce que la plateforme doit savoir faire, comment elle sera observée, à quoi ressemble le coût de l'exploitation en régime stable. Ils partagent un rythme de travail, échangent des évidences dans les deux sens, et arrivent au comité de pilotage avec une seule vue plutôt que deux en concurrence. La manière dont nous organisons généralement le travail dans ces cas, c'est d'écrire un journal de décisions unique dont les deux côtés sont propriétaires, pour que les arbitrages atterrissent à un seul endroit plutôt que de se disperser dans deux decks séparés.

Ce qui reste séparé. Ce qui fait le pont.

Une question courante que nous recevons de clients qui évaluent le modèle, c'est de savoir si les deux moteurs sont vraiment séparés, ou si l'un n'est qu'un emballage léger autour de l'autre. La réponse honnête, c'est que la séparation va plus loin qu'il n'y paraît de l'extérieur, et que les ponts sont plus étroits et plus délibérés qu'on ne le suppose.

Des modèles commerciaux séparés.

Consulting est contractualisé comme du conseil, sur des termes à périmètre fixe ou retainer, avec les livrables et les schémas d'accès qui ont du sens pour ce type de mission. Tech Factory est contractualisé comme de la delivery, avec des critères d'acceptation, des phases de build et un chemin vers l'exploitation. Les deux contrats coexistent quand les deux moteurs sont impliqués ; ils ne sont pas regroupés dans un instrument unique ambigu. Cette clarté protège le client plus qu'elle ne nous protège, parce qu'elle force chaque côté du travail à être défendable à ses propres conditions.

Des rituels de delivery séparés.

Une équipe de conseil qui tient des comités de pilotage à une cadence de deux semaines et une squad Tech Factory qui tient des sprint reviews tous les vendredis n'ont pas besoin de partager une seule cérémonie. Elles ont besoin de partager des évidences. Les rituels de chaque côté restent natifs au travail, et les ponts sont les livrables qui passent entre eux : un document d'état cible que l'équipe build peut implémenter, un architecture decision record que l'équipe conseil peut lire, une capture claire des choix faits pour des raisons business et de ceux faits pour des raisons techniques.

Un vivier d'opérateurs partagé.

Ce qui fait le pont entre les moteurs, ce sont les personnes que nous recrutons. Les consultants experts en Consulting ont généralement un parcours d'ingénierie. Les ingénieurs experts en Tech Factory ont généralement à un moment de leur carrière été face à un comité exécutif. Aucun côté n'est étranger au travail de l'autre. Cette superposition, plus que n'importe quel processus, c'est ce qui permet aux moteurs de se parler quand un dossier en a besoin des deux.

Une discipline d'évaluation partagée.

À travers les deux moteurs, ce que nous considérons comme évidence a la même forme. Une affirmation sur un modèle opératoire devrait pouvoir être testée contre la manière dont le travail s'écoule réellement. Une affirmation sur une plateforme devrait pouvoir être testée contre la manière dont les opérateurs l'utilisent réellement. Le vocabulaire est cohérent ; la rigueur est cohérente. Une recommandation Consulting qui ne peut pas être encaissée dans du travail Tech Factory, ou une release Tech Factory qui ne peut pas être défendue devant le comité opérationnel, est ramenée à la surface avant de devenir un problème.

Un langage de conception partagé.

Les livrables ont l'air de venir du même cabinet. La manière dont nous cadrons une décision, la manière dont nous dessinons une architecture, la manière dont nous structurons un runbook, partagent une discipline visuelle et éditoriale qui tient à travers les dossiers. Ce n'est pas cosmétique. Quand une équipe client lit un document d'architecture Tech Factory et un modèle opératoire cible Consulting côte à côte, le coût cognitif de passer de l'un à l'autre est l'une des choses qui décident si la transformation atterrit.

La discipline opératoire qui garde les deux moteurs cohérents.

Une maison à deux moteurs peut dériver dans deux directions. Un moteur absorbe silencieusement l'autre, et le cabinet devient une boutique stratégie qui écrit aussi du code, ou un éditeur qui donne aussi du conseil. Nous surveillons les deux, et la discipline qui garde les moteurs en équilibre comporte quelques composants simples.

Chaque dossier est staffé par un partner expert sur au moins un côté, et ce partner reste sur le travail de bout en bout. Il n'y a pas de rotation qui retire la personne ayant façonné la recommandation de la salle où le travail est construit, ni de rotation qui retire l'ingénieur ayant bâti la plateforme de la salle où la version suivante est décidée. La continuité est l'assurance la moins chère contre les échecs à deux moteurs que nous avons voulu éviter.

Les deux moteurs tournent sur la même discipline anti-pyramide. Le travail est fait par les personnes dont les noms sont sur le dossier, pas par une équipe junior qui traduit une vue d'expert. C'est vrai du côté stratégie comme du côté build, et c'est l'une des raisons pour lesquelles nos tailles d'équipe paraissent modestes face aux standards des grands cabinets et notre ratio partner/mission paraît élevé.

Les dossiers conjoints ont un seul propriétaire, même quand deux moteurs sont impliqués. Un partner porte la conversation avec le sponsor exécutif, siège à chaque comité de pilotage, et est redevable de la manière dont les deux côtés se connectent. Le partner de l'autre moteur n'est pas invisible ; il est sur le dossier et visible pour le client, mais le modèle opératoire a un seul visage côté client plutôt que deux voix en concurrence.

La question la plus utile à poser à propos d'une transformation, c'est de savoir si les personnes qui l'ont conçue la reconnaîtraient en production. Dans une maison avec deux moteurs sous un même toit, la réponse peut être oui.

Un seul craft, deux muscles.

Nous décrivons parfois B One comme un cabinet de conseil qui construit, parfois comme un éditeur qui conseille. Les deux descriptions sont vraies et toutes deux insuffisantes. Le cadre plus propre, c'est qu'il y a un seul craft, le craft qui consiste à faire passer une entreprise d'un état à un meilleur état, et ce craft a deux muscles. Le muscle stratégique qui décide ce qui doit changer et comment. Le muscle d'ingénierie qui fait vivre et durer le changement. Un cabinet qui possède l'un sans l'autre se heurtera, d'après notre expérience, au même échec prévisible sur un horizon suffisamment long.

Pour les clients qui évaluent le modèle, l'implication pratique, c'est que vous pouvez engager un seul moteur sans vous engager sur l'autre, et que vous pouvez engager les deux sans payer le coût d'intégration qui viendrait normalement avec deux cabinets exploités en parallèle. Les cas publiés sur nos pages réalisations, allant des plateformes de gouvernance de l'innovation dans l'énergie à un déploiement CRM multi-marchés, le lancement d'une marque grand public construite pour l'Asie du Sud-Est et un SaaS hôtelier, se situent quelque part sur ce spectre. Certains sont avant tout des dossiers de conseil. D'autres sont avant tout des dossiers Tech Factory. Ceux qui mobilisent les deux n'ont pas l'apparence de l'un ou l'autre pris isolément.

Si vous pesez une transformation où le côté stratégie et le côté build finiront par se rencontrer, la conversation que nous trouvons généralement la plus utile commence par une question simple. Quelles décisions, sur ce dossier, échoueront si elles sont prises d'un seul côté de cette ligne. Cette question suffit généralement à faire émerger là où les deux moteurs doivent se tenir et là où ils doivent rester en dehors du chemin de l'autre.