Un ingénieur de déploiement en mission
Le montage est simple à décrire : vous obtenez le métier complet d’ingénieur de déploiement sur un projet, sans créer le poste. Comprendre le problème tel qu’il se pose réellement, construire ce qui le résout à l’intérieur de vos systèmes, intégrer, puis rester le temps que les personnes dont le travail change s’en servent effectivement. La mission se termine par une transmission, et ce qu’elle laisse vous appartient sans réserve. Ce qui distingue cela d’une prestation ordinaire n’est pas la compétence technique, qui se trouve ailleurs, mais le point d’arrêt. Une prestation s’achève quand le livrable est conforme. Ici elle s’achève quand le livrable est utilisé, ce qui suppose d’accepter que le périmètre écrit au départ soit faux sur au moins un point important, et de le corriger pendant plutôt que de le défendre. C’est le bon montage pour un premier projet sérieux, et le mauvais pour une organisation qui sait déjà exactement ce qu’elle veut construire.
Ce que couvre la mission
Le diagnostic. Une à deux semaines pour regarder comment le travail se fait réellement, ouvrir les données plutôt que leur documentation, et établir le plafond atteignable. C’est la phase la plus rentable et celle qu’on cherche le plus souvent à raccourcir. Elle se conclut par une recommandation écrite, y compris celle de ne rien construire.
La construction. Le système lui-même, dans votre environnement, avec vos contraintes d’accès et vos fenêtres de mise en production. Quelque chose devant un utilisateur réel dans les premières semaines et non à la fin, parce que la première version sera fausse d’une manière que personne n’avait anticipée.
L’intégration. La partie que les devis sous-estiment le plus. Les authentifications, les autorisations, les formats qui changent sans prévenir, les systèmes amont en maintenance le mardi. Rien de tout cela n’est intellectuellement difficile et tout cela prend du temps réel.
L’adoption. Du temps passé à côté des personnes qui utilisent le système, à regarder ce qu’elles font quand le résultat les surprend. C’est ce qui sépare un projet livré d’un projet qui sert, et c’est la ligne que les prestations classiques n’ont pas.
La transmission. La documentation, le jeu d’évaluation, et une période où l’une de vos personnes exploite le système pendant que nous répondons à ses questions. Traitée comme un livrable et non comme une réunion de clôture.
Quand ce montage est le bon
Il l’est quand le problème est réel mais mal cerné. Vous savez qu’une tâche coûte trop cher, vous ne savez pas encore si c’est un problème de données, d’outil ou d’organisation, et recruter pour cela reviendrait à parier sur un diagnostic que personne n’a posé.
Il l’est aussi quand le besoin est ponctuel. Un déploiement réussi ne crée pas nécessairement un poste permanent : il crée un système qu’une équipe existante peut exploiter. Recruter un profil rare pour une mission de trois mois est une façon coûteuse de découvrir qu’il n’y avait pas de deuxième projet.
Il l’est enfin quand la vitesse compte davantage que la capitalisation. Un recrutement demande trois à six mois entre la décision et la première ligne de code utile, et une part des projets ne survit pas à ce délai parce que la priorité qui les portait a changé.
Quand il ne l’est pas
Si vous avez une équipe technique solide et que le problème est bien compris, construisez-le vous-mêmes. Vous le ferez moins cher, et surtout la connaissance restera chez vous, ce qui compte plus sur trois ans que n’importe quelle vitesse qu’un intervenant extérieur peut ajouter.
Si vous prévoyez une suite de projets semblables, recrutez. Le montage en mission est avantageux sur un projet et cesse de l’être au troisième : à ce stade, l’essentiel de la valeur tient à la connaissance accumulée de vos systèmes, et cette connaissance doit appartenir à quelqu’un qui reste.
Et si le vrai obstacle est que deux directions ne s’accordent pas sur la propriété d’un processus, aucun ingénieur ne corrigera cela. Le projet consommera du budget pendant que le problème restera où il est. Nous le dirons pendant le diagnostic, et c’est l’une des raisons pour lesquelles cette phase existe.
Ce que vous recevez à la fin
Le code, les consignes données au modèle, le jeu d’évaluation, la documentation d’exploitation et la liste écrite de ce qui a été laissé de côté avec la raison. Le tout vous appartient sans licence retenue et sans dépendance construite volontairement.
Le jeu d’évaluation mérite une mention particulière parce que c’est le livrable le plus sous-estimé. Il contient vos propres dossiers, étiquetés par vos propres experts, et il constitue la seule façon de savoir si le système se dégrade après notre départ, quand un fournisseur changera une version de modèle sans vous prévenir. Une entreprise qui garde ce jeu à jour conserve la main. Une entreprise qui ne l’a pas découvre les régressions par les plaintes de ses utilisateurs, six semaines plus tard.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
