La différence entre un fournisseur et un partenaire se voit rarement dans le pitch. Les deux peuvent présenter une proposition soignée, un calendrier raisonnable et un portfolio crédible. La différence apparaît six mois après le lancement, quand quelque chose doit changer, qu'un bug surgit dans une partie du système que personne n'a touchée depuis la livraison, ou que l'entreprise elle-même a dépassé les hypothèses sur lesquelles la construction initiale reposait. Un fournisseur a livré ce qui était spécifié et considère la relation terminée. Un partenaire attendait ce moment et a construit en conséquence.
Ce qu'un fournisseur optimise
L'incitation d'un fournisseur est de clôturer efficacement le contrat en cours : respecter le cahier des charges, tenir le délai, livrer, passer au client suivant. Ce n'est pas malhonnête — c'est simplement une relation différente de celle dont la plupart des entreprises ont réellement besoin en matière de technologie, car un cahier des charges écrit avant qu'un système n'existe n'est jamais le dernier mot sur ce que ce système devrait faire. Un fournisseur traite les écarts par rapport à ce cahier des charges comme une dérive de périmètre à facturer séparément. Un partenaire les traite comme le processus normal et attendu pour construire quelque chose qui fonctionne dans l'entreprise réelle, pas seulement sur le papier.
Des questions qui font ressortir la différence avant de signer quoi que ce soit
« Que se passe-t-il après le lancement ? » La réponse d'un fournisseur est généralement un forfait de support facturé à l'heure ou au ticket. La réponse d'un partenaire inclut généralement ce qu'il s'attend à voir changer dans les trois premiers mois, car il pense déjà au système comme à quelque chose qui évolue plutôt que comme à quelque chose qui se livre et se termine.
« Qui d'autre aura accès à cela une fois en production ? » Cette question révèle si l'entreprise prévoit de transmettre une vraie propriété — identifiants, code source, documentation — ou entend rester la seule partie capable de toucher au système. Une réponse qui évite les précisions ici mérite d'être prise au sérieux comme un signal d'alerte, pas comme un détail à régler plus tard.
« Qu'auriez-vous construit différemment si le brief avait été erroné ? » Un partenaire a une réponse, car il a déjà repoussé certaines parties du brief qui ne tenaient pas la route, plutôt que de construire exactement ce qui était demandé et de laisser le client découvrir l'écart plus tard. La réponse d'un fournisseur ici est souvent qu'il a construit conformément au cahier des charges, ce qui paraît responsable et ne l'est généralement pas.
« Pouvez-vous me montrer une relation client qui a duré au-delà du premier projet ? » La liste de clients d'un fournisseur est surtout faite de missions ponctuelles. La liste de clients d'un partenaire inclut des entreprises qui travaillent encore avec lui des années plus tard, un signal plus fort qu'aucun projet isolé dans le portfolio.
Pourquoi cela compte davantage pour les petites entreprises
Une grande entreprise peut se permettre d'engager un fournisseur pour une tâche étroite et bien spécifiée, et de gérer la relation en interne avec sa propre équipe technique. Une petite entreprise, en général, ne le peut pas — elle n'a pas l'expertise interne pour repérer un mauvais cahier des charges avant qu'il ne soit construit, ni pour gérer l'évolution d'un système sans aide extérieure. Pour une entreprise dans cette situation, la relation technologique elle-même fait partie de ce qui est acheté, pas une formalité autour du code livré, ce qui explique en partie pourquoi le processus sur lequel repose un projet compte autant que le logiciel qu'il produit — une relation bien gérée absorbe les surprises de la même façon qu'un processus bien cartographié. Notre équipe logicielle est organisée pour continuer à travailler avec ses clients après la livraison, précisément parce que c'est à ce moment-là que les vrais besoins d'un système deviennent généralement clairs.
