"On a déjà essayé, ça s'est mal passé."
Je l'entends souvent en premier rendez-vous, et longtemps je l'ai prise pour une objection commerciale, le genre de phrase qu'on sort pour négocier. C'en est rarement une. C'est une donnée. Il y a eu un projet, un prestataire, et quelque chose qui a dérapé au point que la personne en face de moi préfère le dire tout de suite.
Quand on creuse un peu, la compétence technique est rarement en cause. Le développeur savait faire. Ce qui a lâché, c'est ce qui n'avait pas été dit au départ : qui parle au client, ce qu'on fait quand ça déborde, comment on s'annonce qu'on est en retard.
Je travaille en renfort d'agences depuis 2018, et l'une d'elles me confie ses projets Drupal depuis. Ce qui veut dire qu'on a eu le temps de se planter tous les deux et d'en tirer quelque chose. Voilà ce que j'ai vu casser dans une sous-traitance Drupal, des deux côtés. Parce qu'un cadre a deux côtés, et qu'un article où seul le client a des choses à améliorer serait surtout un article malhonnête.
Ce qui coince du côté de l'agence
Rien de ce qui suit n'est une faute professionnelle. Ce sont des habitudes de fonctionnement interne qui marchent très bien avec une équipe intégrée, et qui coûtent cher dès qu'on ajoute quelqu'un d'extérieur.
Les accès arrivent après le démarrage
Le classique absolu. La mission commence lundi. Le dépôt git arrive jeudi. La préproduction n'existe pas, on s'en aperçoit vendredi. L'accès à la production remonte la semaine suivante, et l'accès au serveur de mails jamais, parce que le compte était au nom de l'ancien prestataire.
Pendant ce temps, le freelance lit du code sans pouvoir l'exécuter. C'est le moment le moins productif d'une mission, et il est intégralement évitable. Facturé ou non, ce temps est perdu pour tout le monde : si vous ne le payez pas, vous le récupérez sous forme de retard.
Le geste qui règle ça tient en un mail envoyé avant le démarrage, avec la liste nominative des systèmes : dépôt, hébergement, base, administration Drupal, DNS, fournisseur de mails, services tiers. Cinq minutes d'écriture, une semaine gagnée.
Le chiffrage demandé sans le code
"Chiffre-moi cette évolution." Une capture d'écran, trois lignes de mail, et une réponse attendue dans l'après-midi parce que le client relance.
Je comprends la contrainte, elle est réelle. Mais pour donner un chiffre que je tiendrai, il me faut trois choses : voir le modèle de contenu, savoir si un comportement approchant existe déjà quelque part sur le site, et savoir ce qui a déjà été tenté. Sans ça, je ne chiffre pas une évolution, je chiffre une capture d'écran.
Il y a une sortie honnête, et elle marche : une fourchette avec ses facteurs de variation. "Entre deux et six jours, deux si le champ existe déjà sur ce type de contenu, six s'il faut le créer et reprendre les contenus existants." C'est moins confortable qu'un chiffre net. C'est infiniment plus solide, parce qu'un chiffre net donné sans le code est une promesse qu'on tiendra au détriment de quelqu'un, en général du développeur qui finit le week-end.
Le ticket qui n'est pas un ticket
"Ça marche pas chez le client."
Sur quel environnement, avec quel rôle utilisateur, depuis quand, après quelle action exacte, et est-ce que quelqu'un a ouvert les journaux avant de transférer ? La question n'est pas morale, elle est comptable : le temps de reconstitution du contexte est facturé au même tarif que le développement, et il est beaucoup moins utile.
Quand une agence prend l'habitude de transférer les tickets bruts, elle achète du travail d'enquête au prix du travail d'expert. Trois lignes de contexte en plus, et le rapport s'inverse.
La frontière avec le client final laissée floue
Marque blanche complète ou sous-traitant déclaré : les deux fonctionnent très bien. J'ai travaillé dans les deux configurations et aucune n'est supérieure à l'autre.
Ce qui ne fonctionne pas, c'est de ne pas trancher, et de le découvrir en réunion. Ça produit deux situations symétriques, et j'ai vécu les deux. Le client qui ignore l'existence d'un prestataire et qui découvre un inconnu dans la visio. Et le prestataire présenté comme membre de l'équipe, à qui le client adresse directement une demande hors périmètre, sans que personne ne sache qui doit dire non.
Une phrase suffit à trancher. Ne pas la poser coûte cher jusqu'à la fin du projet.
Confondre disponibilité et capacité
"T'es dispo là ?"
Une disponibilité se constate après coup. Une capacité se réserve avant. Tant qu'on travaille sur le premier mode, l'agence n'a aucune garantie et le freelance n'a aucune visibilité : chacun optimise dans son coin, et la première urgence sérieuse arbitre à la place de tout le monde. C'est précisément le problème que résout une capacité réservée à l'avance, et c'est la seule raison pour laquelle ce modèle existe.
Ce qui casse de mon côté
Voilà la partie que les pages de sous-traitance ne contiennent jamais. Elle est pourtant plus utile que la précédente, parce qu'elle vous dit quoi surveiller chez celui que vous allez recruter, y compris chez moi.
Dire oui de trop
Deux agences, deux urgences légitimes, la même semaine. J'ai dit oui aux deux, en me disant que ça passerait en serrant un peu.
Ce que ça produit n'a rien de spectaculaire. Personne n'est mal servi de façon visible. Tout le monde est servi un peu moins bien : les réponses mettent une demi-journée au lieu d'une heure, les livraisons glissent d'un cran, et la qualité de l'attention baisse sans que ça se voie sur une facture. C'est pire qu'un refus franc, parce que ça ne déclenche aucune alerte.
C'est ça que règle la capacité réservée, et le mécanisme est moins commercial qu'il n'en a l'air. C'est le seul dispositif qui rend un "non" possible sans casser la relation : quand les jours sont déjà bloqués, refuser cesse d'être un désengagement pour devenir le respect de ce qui a été convenu.
Le silence quand je bloque
Mon réflexe naturel est de vouloir revenir avec la solution plutôt qu'avec le problème. Ça part d'une bonne intention et c'est une mauvaise idée.
Quarante-huit heures de silence coûtent plus cher à l'agence qu'un message qui dit "je bloque sur le comportement du module de recherche, voilà où j'en suis, voilà les deux pistes que je vais essayer". Parce que pendant que je cherche en silence, quelqu'un chez vous a un client à informer et n'a rien à lui dire.
Ça m'a pris du temps à comprendre. Le silence protège mon confort, il transfère l'inconfort à celui qui porte la relation client.
Livrer techniquement juste et fonctionnellement à côté
Quand je n'ai jamais vu le brief d'origine, je résous le ticket. Pas le besoin.
Le résultat est du code correct, testé, qui fait exactement ce qui était demandé, et qui rate le sujet. La responsabilité est partagée, le brief n'a pas circulé. La conséquence, elle, n'est pas partagée du tout : c'est l'agence qui présente le résultat au client.
Ce qui répare ça, c'est une question bête, posée dès le premier point : à quoi ça sert pour l'utilisateur ? Elle a l'air déplacée sur un ticket de trois heures. Elle a sauvé plus de livraisons que n'importe quelle relecture de code.
Le "tant que j'y étais"
J'ouvre un fichier pour corriger un bug, et je trouve trois horreurs à côté. Je les corrige. J'ai bien travaillé.
Sauf que je viens de livrer un diff que personne ne peut relire sérieusement, une recette de test que l'agence n'avait pas prévue, et un doute permanent sur l'origine de la moindre régression des trois semaines suivantes. La propreté qu'on n'a pas annoncée n'est pas un cadeau : c'est un risque transféré à celui qui valide.
Aujourd'hui je note ce que j'ai vu et je le propose séparément. C'est moins satisfaisant sur le moment, et beaucoup plus utile ensuite.
La fin de mission bâclée
Le vrai test d'un sous-traitant n'est pas ce qu'il livre. C'est ce que l'équipe suivante trouve.
Une branche non fusionnée sans explication, un correctif appliqué directement en production et jamais reporté dans le dépôt, une décision d'architecture prise pour de bonnes raisons et documentée nulle part : voilà ce qui coûte cher, six mois plus tard, à celui qui reprend. Et il le paiera dans les vérifications qu'il fera de toute façon en reprenant le projet, sauf qu'il mettra deux jours à comprendre ce qu'une note de dix lignes aurait expliqué.
Où passe vraiment la frontière
Tout ce qui précède se ramène à une seule question : qui porte quel risque.
L'agence porte le risque relationnel. C'est sa signature sur la livraison, son client, sa réputation locale, et c'est elle qui prendra le coup de fil du lundi matin. Le freelance porte le risque technique. C'est ce qu'il a écrit, ce qu'il a cassé, ce qu'il n'a pas vu.
Les collaborations qui tiennent sont celles où chacun assume le sien sans essayer de le déplacer sur l'autre. Une agence qui rend le prestataire responsable de la relation client se met en danger. Un freelance qui rend l'agence responsable de la qualité de son code aussi.
Trois choses se figent au démarrage, et ça prend un quart d'heure : qui parle au client, ce qu'on fait quand une demande sort du périmètre, et comment on se dit qu'on est en retard. Le reste s'ajuste en route.
Quand la sous-traitance n'est pas la bonne réponse
Il y a des situations où la bonne recommandation est de ne pas prendre de prestataire externe, moi compris.
Un besoin permanent à plein temps se recrute. Le calcul finit toujours par le dire, autant le faire avant. Un renfort externe est fait pour absorber une pointe, couvrir un départ, ou apporter une compétence qu'on ne veut pas internaliser. Pour tenir un poste, il coûte plus cher et il tient moins bien.
Un projet que personne dans l'agence ne peut relire pose un problème qu'un externe ne résoudra pas. Il le déplacera. Il faut quelqu'un capable de valider, même partiellement, même sur les seuls points structurants, sinon vous remplacez une dépendance par une autre et vous avez juste changé de nom sur la facture. C'est le même mécanisme que la difficulté à recruter sur du legacy : le problème n'est pas le marché, il est dans ce que le code exige de celui qui arrive.
Une urgence isolée sur un site inconnu, c'est possible, mais le temps de prise en main est incompressible. Il vaut mieux l'annoncer que le découvrir sur la facture.
La bonne question avant de sous-traiter
La question à se poser n'est pas "est-ce qu'il sait faire". Vous le verrez en trois jours, et c'est rarement là que ça casse.
C'est : est-ce qu'on saura se dire les mauvaises nouvelles assez tôt. Le retard, le blocage, le devis sous-évalué, la décision qu'on regrette. Une collaboration technique tient sur cette mécanique-là, et le reste s'apprend en route.