Ces missions ont été menées avec Cœur du Web, l'agence que j'ai fondée. Elles sont réécrites ici du point de vue du pilotage. Les faits, les chiffres et les noms de clients publics proviennent des dossiers de mission ; un des trois cas est explicitement reconstitué et anonymisé, il le signale en tête de page.
Les trois missions
Trois contextes sans rapport : une équipe produit qui n'avançait plus chez un spécialiste du lead B2B, un tableur critique au cœur d'une PME industrielle, et une infrastructure numérique publique construite pour un État. Le point commun tient dans la façon dont chacune s'est terminée.
- Une équipe produit qui ne livrait plus. Une direction qui ne savait plus quoi exiger de ses développeurs. Le cadre reposé, un product owner interne recruté et formé, la mission rendue.
- Le fichier Excel qui porte toute l'entreprise. Un tableur de plusieurs dizaines de mégaoctets, la double saisie partout, et personne qui ose y toucher. Cas reconstitué à partir de plusieurs missions.
- Une infrastructure publique livrée avec ses sources et son équipe. Deux composantes sans équivalent sur le marché, construites pour être reprises par ceux qui allaient les exploiter. La page contient le reportage France 2 consacré au socle technique de ces deux composantes.
Ce qu'elles ont en commun
Rien, sinon la question posée à la fin : qu'est-ce qui reste chez le client quand l'intervenant s'en va ?
Dans les trois cas, la réponse était une personne formée, pas un contrat de maintenance. Un product owner interne, un référent capable de modifier les règles métier, trois développeurs locaux montés en compétence sur le projet. C'est le critère que j'utilise pour juger mon propre travail, et celui que je conseille d'écrire dans un cahier des charges avant de comparer des propositions.
L'autre point commun est moins flatteur et mérite d'être dit : aucune des trois missions n'a commencé par un problème technique. Deux commençaient par un problème d'organisation, la troisième par une contrainte politique de souveraineté. La technique n'est presque jamais le sujet de départ.
Ce fil conducteur n'est pas propre à ces trois missions : c'est la méthode que j'applique, et elle est résumée sur la page d'accueil.
Ce que ces pages ne disent pas
Trois choses, volontairement absentes.
- Les budgets. Ils appartiennent aux clients, pas à moi.
- Les durées exactes. Elles ne veulent rien dire hors de leur contexte, et une mission courte n'est ni un exploit ni un aveu.
- Les échecs. Ils existent, ils ne sont pas racontés ici faute d'accord des clients concernés. C'est une limite de tout portfolio, y compris celui-ci.
Si vous cherchez plutôt la méthode que les exemples, elle est décrite dans mon guide de la gestion de projet digital, et le format d'intervention dans la page sur l'externalisation du pilotage.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des refontes, des applications métier et des plateformes pour le compte de ses clients, face aux agences et aux équipes techniques, pour des grands comptes comme pour des PME. Découvrir son approche.
À lire ensuite
Une équipe produit qui ne livrait plus
Le cadre reposé, un product owner interne recruté, la mission rendue.
Le fichier Excel qui porte l'entreprise
Ce qu'on regarde avant de le remplacer, et par quoi.
Une infrastructure publique transmissible
Sources livrées, hébergement transféré, équipe locale formée.
Externaliser le pilotage
Le format d'intervention derrière ces trois missions.