Photo de couverture de l'article où plusieurs collaborateurs theTribe assistent à une présentation réalisée par les deux fondateurs de theTribe, Benoît Vasseur et Jérôme Vasseur.
Entrepreneuriat | Expertise

Notre métier, c’est de résoudre des problèmes, pas vendre des jours-hommes

Publié le : 10 juin 2024
Temps de lecture : 11 minutes

Depuis la création de theTribe, nous avons accompagné des centaines de projets innovants. De la création d’un MVP en 6 semaines à l’accompagnement de PME pendant 3 ans, nous avons expérimenté différentes approches, et nous avons énormément appris.

Avant d’être des experts produit et des passionnés d’entrepreneuriat, nous sommes avant tout une agence dont le métier est de développer des solutions web et mobiles. Mais nous ne sommes pas une ESN qui se contente de vendre des jours-hommes pour réaliser les projets de nos clients. Parce que ça ne marche pas. 

Dans cet article, Benoît, Cofondateur et CEO de theTribe, partage nos recettes pour des projets qui réussissent vraiment.


Sommaire :


Pourquoi les entreprises sous-traitent leurs projets web et IT ? 🤔

Lorsqu’une entreprise vient nous voir pour obtenir du renfort technique, ou pour nous confier le développement d’un logiciel, elle n’a pas seulement besoin de petites mains pour produire du code. En général, elle cherche un prestataire car elle a un problème à résoudre.

Cela peut être un problème de dette technique : l’entreprise a construit un produit couche par couche, en ajoutant de nouvelles fonctionnalités au fil de l’eau, et petit à petit, la dette s’est accumulée. Les équipes n’arrivent plus à prendre du recul, le produit est instable, il devient de plus en plus difficile de le faire évoluer, bref : on ne s’en sort plus.

Parfois, c’est un problème de méthodologie projet qui conduit une entreprise à faire appel à une expertise externe. L’équipe a développé un produit à l’intuition, elle a avancé en faisant, mais elle réalise à un moment qu’elle manque de cadre, et qu’elle a besoin de structurer ses méthodes.

Dans d’autres cas, c’est un manque de ressources internes (temps, expertise) qui amène à chercher un prestataire : parce que l’entreprise grossit trop vite et qu’il est difficile de recruter et former, ou parce qu’il manque une compétence technique précise dans l’équipe. Le besoin ici n’est pas seulement de prendre des développeurs pour les faire coder : le besoin sous-jacent est un besoin d’expertise et d’accompagnement.

Le dernier cas de figure est celui où l’entreprise a déjà essuyé un échec. Elle a développé un produit qui n’a pas trouvé son marché, un outil qui n’a jamais été adopté par les utilisateurs. Ou bien elle a lancé un projet qui n’a jamais été terminé. Alors elle décide d’aller chercher de l’expertise externe, qui va l’aider à ne pas renouveler cet échec.

Pourquoi l’externalisation ne résout pas ces problèmes ? ❌

Si vous vous êtes reconnu dans un des cas de figure précédents, peut-être qu’à ce stade, vous vous dites que l’externalisation n’est pas la réponse à ces problèmes. Parce que vous avez essayé, et que ça n’a pas marché. Et vous avez raison.

Faire appel à un prestataire externe ne résout pas la dette technique, ne règle pas vos projets d’organisation interne, n’aide pas vos équipes à monter en compétences, ne permet pas à votre produit de convaincre vos clients et utilisateurs. Et parfois, même en externalisant, les projets n’avancent pas et ne sortent jamais.

Parce qu’on prend les choses par le mauvais bout. 

Au fond, qu’est-ce qui se passe, lorsque l’on fait appel à un sous-traitant pour un projet web ou logiciel ?

1. On empile des ressources 

On prend des développeurs et des développeuses, on les met dans une salle et on leur demande de coder. Alors que parfois, ils n’ont jamais travaillé ensemble. Sans s’assurer qu’ils suivent une méthodologie commune. Avec au mieux un chef de projet qui répartit les tâches.

2. On “fait faire”

On donne un cahier des charges, des spécifications, et on demande au prestataire d’exécuter. Mais on ne lui demande pas d’être proactif et de remplir son devoir de conseil :  sur les choix techniques, les choix business, la priorisation des fonctionnalités, la méthodologie projet.

On fait comme on a toujours fait : on suit ses intuitions, on délivre des fonctionnalités, sans prendre de recul.

3. On suit le plan

Corollaire du point précédent : quand on demande à un prestataire de suivre un plan sans le challenger, on croit se sécuriser, mais on court à l’échec. Le problème des roadmaps et des plans, c’est qu’ils nous rassurent. On croit qu’en les déroulant, tout va bien se passer, et on perd de vue les objectifs pour se concentrer sur les moyens. Les CEO tombent amoureux de leur business plan, les chefs de projet, équipes techniques et produit tombent amoureux de leur roadmap. Et les sous-traitants ne les aident pas à faire le pas de côté qui pourrait être nécessaire.

C’est ainsi que les entreprises se retrouvent, au bout du compte, avec les mêmes problèmes que ceux qui, au départ, les ont poussées à externaliser : 

  • Les projets s’enlisent et ne sortent pas ;
  • Les équipes perdent du temps à développer des fonctionnalités qui ne seront jamais utilisées, voire à créer un produit qui finira à la poubelle car il ne répond à aucun besoin business ;
  • Le produit finit par sortir, mais il ne trouve pas son marché.

Les vrais problèmes ne sont pas ceux que l’on croit ⚠️

En travaillant aux côtés de nos clients, nous nous rendons compte que petit à petit, en ouvrant les boîtes les unes après les autres, nous découvrons les vrais problèmes. Et ce ne sont pas ceux pour lesquels ils ont fait appel à nous à l’origine.

Ces problèmes peuvent être de plusieurs natures :

👉 Problèmes d’alignement

Dans la plupart des cas, quand on parle de problèmes d’alignement, c’est que les équipes métier / produit et techniques ne se parlent pas.

Les équipes métier / produit écrivent des specs pour les équipes techniques sans leur expliquer la finalité, l’objectif qui se cache derrière.

Les équipes techniques rencontrent des difficultés au quotidien dans leur travail (dette technique, architecture, performances…) et ne s’en sortent pas, mais la résolution de ces problèmes n’est jamais priorisée car les équipes métier / produit n’ont pas conscience de leur impact. Le serpent se mord la queue.

👉 Mauvaises priorités business

Parfois, en suivant leur plan, les entreprises lancent des projets qui ne devraient pas être prioritaires. Ce n’est pas la faute des dirigeants ni des équipes : c’est juste qu’ils n’ont plus le recul nécessaire pour revoir leur plan et questionner ces priorités.

👉 Manque d’écoute des utilisateurs

Trop souvent, les entreprises avec lesquelles nous travaillons ont arrêté d’écouter leurs utilisateurs. Ce sont les dirigeants et les équipes qui décident quels projets seront priorisés, ce que l’on met dans la roadmap. Et on ne prend pas la peine de prendre en compte les besoins des utilisateurs.

👉 Problème de méthodologie

Certaines entreprises font appel à un prestataire car elles croient qu’elles manquent juste de ressources techniques, et passent à côté de leur vrai problème : elles perdent du temps car c’est leur méthodologie projet qui ne va pas. Manque de communication, problèmes de priorisation, délais à rallonge, sous-qualité : tout cela peut être résolu en changeant d’organisation et de méthode.

👉 Besoin d’expertise technique

Lorsqu’une entreprise rencontre des problèmes techniques complexes, notamment lorsque la dette technique explose, ajouter des ressources ne suffira pas à résoudre la situation. Il faut parfois un regard expert, apporté par une personne expérimentée, capable de challenger l’architecture, de proposer des solutions. Ce qu’un développeur junior “la tête dans le guidon” ne fera pas.

Finalement, lorsque vous vous contentez d’acheter des jours-hommes pour délivrer du code, vous ne traitez pas les bons enjeux.

  • Vous développez des fonctionnalités pour dérouler une roadmap, sans vous poser la question : quel problème je veux résoudre ?
  • Vous enterrez les problèmes de dette technique, d’architecture, de qualité et de performances, sans les résoudre.
  • Vous passez des heures en réunions et à rédiger des compte-rendus mais personne ne se parle vraiment.

L’approche theTribe : Résoudre les problèmes en faisant 🪛 

La vision que je viens de décrire des projets externalisés n’est pas rose. Mais rassurez-vous, il y a des solutions !

Chez theTribe, notre approche d’accompagnement rompt avec le fonctionnement classique des agences et ESN. Oui, nous aussi, nous avons une équipe de développement et oui, nous vendons des jours-homme. Mais de l’intérieur, ça n’a rien à voir.

Pourquoi ?

En résumé : parce que chez theTribe, nous ne nous contentons pas de vendre des jours de développement. Pour chaque projet, nous créons une vraie équipe qui va être dévouée à un seul objectif : résoudre les problèmes de notre client.

Comment ?

En 8 points, voici nos engagements, les valeurs qui font notre différence.

1. Résoudre les problèmes en faisant

Lorsque nous arrivons sur un projet, nous commençons par prendre les sujets un par un. Petit à petit, nous épluchons les couches de l’oignon, et en travaillant, nous allons découvrir et mettre en évidence les différents problèmes. Et proposer des solutions concrètes pour les résoudre.

  • Les priorités sont mal définies ? On va interroger les utilisateurs.
  • Le produit est un prototype qui ne tient pas la route ? On va résoudre les problèmes de dette technique en travaillant sur l’architecture, les tests, etc.
  • Le client n’a pas les bonnes compétences en interne ? On va aller chercher les bons experts.
  • Les équipes du client ne sont pas alignées ? On met en place des rituels, on propose une méthodologie, et on aide les gens à se parler.
  • etc.

2. Partager nos bonnes pratiques

Chez theTribe, on ne vend pas que du temps. 

Lorsque l’on travaille avec un client, on partage aussi nos bonnes pratiques, notre méthodologie, mais pas de façon descendante. 

Petit à petit, on transforme l’organisation du client de l’intérieur en faisant infuser notre approche, et nos clients se l’approprient : 

  • ils apprennent à prioriser en repartant des problèmes business
  • ils apprennent à livrer régulièrement, expérimenter, confronter le produit aux utilisateurs pour avoir rapidement des retours
  • ils apprennent à traiter la dette technique au fil de l’eau et arrêter de l’alimenter 
  • etc.

“theTribe nous a aidés sur les choix techniques structurants, et ils ont amené des méthodes, des rituels, que l’on utilise encore aujourd’hui en interne.” 

Laurent Giovannoni, CTO chez HumanCraft

3. Résoudre les problèmes d’alignement

En observant nos clients, nous mettons en évidence les problèmes de communication interne, les raisons pour lesquelles les équipes métier / produit et technique ne se parlent pas : parce qu’ils n’ont pas mis en place les bons rituels, ou parce qu’ils n’écoutent pas assez leurs clients. Et nous les aidons, toujours “en faisant”, à résoudre ce problème.

4. Oser dire la vérité

Une des valeurs de theTribe, c’est l’honnêteté intellectuelle. Quand quelque chose ne va pas, quand on détecte un problème, nous le mettons sur la table. Même si ce n’est pas ce qu’on attend de nous, et même si c’est inconfortable. 

Mais nous ne nous contentons pas de pointer du doigt ce qui ne va pas. Au lieu de rester en surface, nous mettons en évidence la cause racine du problème, et cherchons des solutions.

“Si ça se passe mal, on en parle, on améliore : la dynamique était très positive et l’équipe investie à 2000%”

Sacha Koubi, co-fondateur Elyos

5. Ne pas tomber amoureux de la roadmap

Nous ne confondons pas les moyens et les objectifs. Chez theTribe, notre priorité ne sera jamais de sortir telle ou telle fonctionnalité. La priorité, ce n’est pas la fonctionnalité, c’est l’objectif business.

6. Transmettre nos compétences

Lorsque nous intervenons en renfort au sein de l’équipe d’un client, nous ne gardons pas notre savoir. Nous n’avons aucun intérêt à rendre le client prisonnier de notre accompagnement. Nous apportons rapidement des solutions, et veillons à rendre notre client autonome pour les pérenniser, grâce à un transfert de compétences systématique. Notre objectif, lorsque nous résolvons un problème, c’est que notre client ait compris comment et qu’il puisse le refaire lui-même.

“Tout se déroule dans un esprit de partage et d’amélioration continue avec le souhait d’apporter des bonnes pratiques adaptées à notre contexte. Aujourd’hui, nous avons gardé en interne la même dynamique et nous pouvons continuer sur cette lancée. On a bougé grâce à theTribe !”

Guillaume de Kergariou, Fondateur et CEO de NeedHelp

7. Mettre en place une équipe

Lorsque nous intervenons pour un client, nous ne nous contentons pas de piocher dans les ressources disponibles. Les membres de notre équipe ne sont pas des pions. Nous créons une équipe, cohérente, composée de personnes complémentaires et qui savent travailler ensemble. Tous les membres de notre équipe (développeurs, product manager, designers…) sont formés à notre méthodologie et partagent notre vision. Et cette équipe devient une extension de la vôtre, le temps de notre collaboration.

8. Garder notre recul

On nous demande souvent pourquoi, chez theTribe, nous n’envoyons pas notre équipe “chez le client”, comme cela se fait dans les ESN. La raison est très simple : c’est ce qui leur permet de garder le recul nécessaire pour apporter une réelle valeur ajoutée à nos clients.

En travaillant au quotidien immergés au sein des équipes des clients, les collaborateurs des ESN finissent par être plus proches de leur client que de leur employeur. Ils perdent le contact avec leurs collègues et finissent par embrasser les méthodes du client.

C’est l’inverse de notre vision d’une collaboration réussie, qui se base sur un enrichissement mutuel et la transmission de nos méthodes aux équipes de nos clients.

Comment nous transformons nos clients : un exemple concret 📝

Récemment, nous sommes intervenus au sein d’une entreprise de 100 collaborateurs, une belle scale up qui rencontrait deux problèmes majeurs : 

  • Elle faisait face à une dette technique grandissante : la plateforme web au cœur de son activité “crashait” régulièrement. Une refonte technique en profondeur était nécessaire, mais n’avançait pas.
  • Certains chantiers produit restaient bloqués dans la roadmap et ne réussissaient pas à être priorisés.

En apportant du renfort à ce client, nous avons réalisé que l’équipe technique et l’équipe produit ne se parlaient pas. L’équipe produit transmettait des demandes et rédigeait des spécifications techniques très précises, mais sans expliquer le “pourquoi” caché derrière ces besoins. Résultat : ces demandes n’étaient jamais prioritaires pour l’équipe technique, engluée dans des problèmes de performance et de stabilité de la plateforme.

Alors, qu’avons-nous fait ?

Nous avons commencé par faire aux côtés de l’équipe technique et de l’équipe produit. Cela nous a permis de nous imprégner de la culture du client, de comprendre les circuits dans la prise de décision, les rituels entre les équipes, les processus opérationnels.

Cela nous a permis de comprendre que la cause racine de la dette technique n’était pas la compétence de l’équipe technique, c’était un problème d’alignement sur les enjeux, un problème de manque d’empathie, de compréhension commune des enjeux de pôles qui fonctionnent en silos.

Nous avons mis l’équipe technique et l’équipe produit dans la même pièce, pour qu’ils se parlent, et pour les aider à faire le tri dans leurs besoins. Chacun a eu la parole, chacun est rentré dans une meilleure compréhension des enjeux de l’autre et nous avons ensuite présenté la situation à la direction. Nous avons mis le doigt sur les problèmes à résoudre et avons proposé et mis en place plusieurs actions concrètes : 

  • Organiser des ateliers pour redéfinir la vision produit ; Le livrable qui en découle est une roadmap orientée par les objectifs business : chacun parle le même langage, on sait pourquoi on fait ou on ne fait pas certaines choses et on avance tous dans la même direction.
  • Mettre en place une mission d’expertise technique pour définir une architecture cible : chaque modification, correction de bugs permet de s’approcher d’une architecture cible, en somme, d’une vision technique partagée.

Pour voir un autre exemple concret d’accompagnement, lisez l’étude de cas Humancraft : Accélérer sa roadmap et structurer l’équipe tech après une levée de fonds

Une approche qui permet aux entreprises de se transformer en douceur 🎯

Si vous êtes arrivés jusqu’ici, vous avez compris notre vision de l’externalisation : il ne s’agit pas de vendre uniquement de l’exécution, ni d’imposer une méthode à marche forcée à des clients qui ne sont pas prêts pour cela. Nous préférons faire évoluer petit à petit les organisations et les méthodes de travail de nos clients, en nous appuyant sur notre expérience, notre expertise et en réglant les problèmes un par un.

Notre vision, notre méthode restent la même que lorsque nous proposons un Design Sprint et une approche Produit à une start-up qui démarre : partir des besoins business et des attentes des utilisateurs pour construire des produits qui atteignent leurs objectifs.

Simplement, nous savons que l’organisation d’ateliers UX Design et Produit n’est pas la réponse attendue par une entreprise qui a des problèmes concrets à résoudre et veut des résultats rapidement.

Lorsque nous sommes face à une entreprise mature qui sait (ou croit savoir) ce dont elle a besoin, nous commençons par mettre un pied dans les projets. C’est en donnant des résultats concrets que l’on va faire infuser notre méthode et notre vision, en revenant à l’essentiel : de quoi l’utilisateur final a besoin ?

En travaillant au quotidien avec nos clients, nous gagnons petit à petit leur confiance et la légitimité nécessaire pour amorcer le changement : 

  • En mettant l’utilisateur au cœur de la stratégie, on réaligne les équipes et on casse les silos ;
  • En résolvant les problèmes un par un et en aidant nos clients à prendre les bonnes décisions ;
  • En apportant des méthodes qui permettent d’aller plus vite et d’offrir à chacun l’opportunité d’apporter des idées ;
  • En amenant de nouvelles compétences lorsque c’est nécessaire.

C’est grâce à notre expertise, notre honnêteté et notre engagement que nous gagnons la confiance de nos clients, avec toujours un objectif en tête : les aider à réussir leurs projets.

“theTribe nous a apporté un livrable et bien plus encore : une nouvelle approche UX, des méthodologies et des pratiques qui nous ont rendu meilleurs et plus efficaces. theTribe a été un bon accélérateur de développement pour nous.” 

Guillaume de Kergariou, Fondateur et CEO de NeedHelp

Benoît Vasseur
Cofondateur & CEO @theTribe