La plupart des processus de sélection comparent le prix et les références. Ni l'un ni l'autre ne prédit bien le résultat. Voici les vérifications qui le font — y compris les clauses contractuelles qui décident si vous pourrez partir.
Choisir un partenaire de développement est difficile précisément parce que ce que vous évaluez est le domaine dans lequel l'expertise vous manque. Le processus habituel — recueillir trois devis, regarder les références, retenir un montant qui vous met à l'aise — sélectionne la capacité commerciale plutôt que la capacité à livrer. Voici ce qui prédit réellement le résultat.
Établissez qui fera le travail
Demandez-le directement : les personnes présentes à cette réunion construiront-elles le système ? Dans une part non négligeable des missions, les profils seniors qui présentent ne sont pas ceux qui livrent, et le travail passe à une équipe plus junior ou est entièrement sous-traité. Ce n'est pas automatiquement rédhibitoire, mais vous devriez le savoir avant de signer plutôt qu'au premier point d'avancement.
- Qui précisément écrira le code, et quelle est son expérience de ce type de système ?
- Le travail sera-t-il sous-traité, en totalité ou en partie ?
- Qui est mon interlocuteur quand quelque chose ne va pas, et quel est son pouvoir d'y remédier ?
- Que se passe-t-il si le développeur principal part en cours de projet ?
Vérifiez les références plutôt que le portfolio
Un portfolio montre ce qui a été livré. Il ne montre pas si c'était en retard, si le budget a doublé, ni si le client referait appel à eux. Demandez deux références : une récente, et une portant sur un projet terminé depuis au moins un an. La seconde est plus révélatrice — elle vous dit si le logiciel fonctionnait et était encore soutenu une fois les factures terminées.
Observez ce qui se passe quand vous posez une question difficile
Décrivez une exigence réellement difficile ou ambiguë et voyez ce qui revient. Un prestataire compétent pose des questions de clarification, identifie les risques, et peut vous dire que l'exigence telle qu'énoncée est une mauvaise idée. Un prestataire moins compétent acquiesce avec enthousiasme et chiffre immédiatement.
La disposition à vous contredire pendant la phase commerciale fait partie des indicateurs les plus fiables dont vous disposez. Quelqu'un qui dit oui à tout avant qu'un contrat n'existe ne développera pas soudainement du discernement une fois celui-ci signé.
Les clauses contractuelles qui comptent
| Clause | Ce que vous voulez | Pourquoi |
|---|---|---|
| Propriété intellectuelle | Vous possédez tout le code et les ressources au paiement | Sans cela, vous pourriez licencier votre propre système |
| Accès au dépôt de code | Sur le compte de votre organisation, dès le premier jour | Vous voyez l'avancement et vous n'êtes pas exclu en cas de litige |
| Hébergement et noms de domaine | Enregistrés à votre nom | La forme de captivité la plus courante, et la plus facile à éviter |
| Processus d'évolution | Écrit, avec une tarification convenue à l'avance | Évite de renégocier chaque ajustement |
| Critères de recette | Définis par phase avant son démarrage | Donne à « terminé » un sens objectif |
| Conditions de sortie | Transfert documenté inclus | Vous finirez par vous séparer, à l'amiable ou non |
La clause la plus utile de toutes est l'accès au dépôt de code dès le premier commit. Elle ne coûte rien à un prestataire compétent et confiant, et une réticence à l'accepter vous apprend quelque chose d'important.
Des signaux à traiter comme des avertissements
- Un devis ferme produit sans cadrage sérieux. Soit l'estimation relève de la devinette, soit le périmètre est défini assez lâchement pour être discuté plus tard.
- Des positions garanties dans les moteurs ou un trafic garanti. Personne ne contrôle les résultats de Google, et prétendre le contraire traduit une incompréhension ou une tromperie.
- Une réticence à vous donner accès au dépôt, ou un hébergement détenu au nom du prestataire.
- Une proposition entièrement composée de noms de technologies sans aucune référence à votre problème métier.
- Une pression pour signer vite au bénéfice d'une remise qui expire.
- Aucune conversation sur la maintenance. Un prestataire qui n'aborde pas les coûts récurrents est soit inexpérimenté, soit vous laisse les découvrir.
- Des témoignages sans nom ni entreprise attribuables.
Un processus de sélection raisonnable
- Écrivez le problème métier, en termes métier. Pas la solution que vous avez imaginée — le problème, et à quoi ressemblerait le succès sous forme de mesure.
- Approchez trois ou quatre prestataires dont l'expérience colle plausiblement. Au-delà, vous diluez l'attention que vous pouvez donner à chaque échange.
- Payez un cadrage avec le ou les deux prestataires que vous préférez. Un cadrage payant produit un vrai périmètre et vous montre leur façon de travailler avant l'engagement important.
- Comparez les propositions sur le périmètre et les exclusions, pas sur le montant affiché.
- Prenez des références, dont un projet plus ancien.
- Commencez par un travail réel et de petite taille si vous le pouvez. Une première phase à valeur réelle est un bien meilleur test que n'importe quel entretien.
- Lisez le contrat sérieusement, en prêtant une attention particulière à la propriété intellectuelle, à la gestion des évolutions et à la sortie.
Sur l'offshore, le nearshore et le local
Il existe partout de bons et de mauvais ingénieurs, et la localisation prédit la qualité bien moins qu'on ne le suppose. Ce que la localisation affecte, c'est le coût de communication. Un large décalage horaire fonctionne bien avec des besoins clairement documentés et quelqu'un de votre côté qui pilote activement la relation ; il fonctionne mal avec un cahier des charges mouvant qui demande une conversation quotidienne.
Soyez simplement pratique : si vos besoins sont encore en formation, privilégiez le recouvrement des horaires de travail. S'ils sont bien documentés et stables, un écart plus large reste gérable et la différence de coût peut être réelle. Demandez où l'équipe se trouve réellement plutôt qu'où la société est immatriculée.
La question qui compte le plus
Demandez ce qu'ils feraient si le projet rencontrait des difficultés — une échéance manquée, une exigence qui se révèle impossible, un budget sous tension. La réponse révèle leur façon de penser le risque et de vous considérer. Les prestataires qui livrent depuis des années ont de bonnes réponses parce qu'ils y sont passés. Ceux qui n'ont pas cette expérience vous diront que cela ne leur arrive pas.
C'est le type de travail que nous faisons. Si cela concerne un projet que vous préparez, notre page logiciel sur mesure explique notre approche, ou bien vous pouvez décrire le projet et nous vous dirons ce que nous en pensons.