Avant de choisir un partenaire d'ingénierie logicielle, sachez précisément qui écrira le code, quels systèmes comparables il a livrés, comment le périmètre et la recette sont définis, et à qui appartient le code dès le premier jour. Des réponses floues à l'une de ces questions sont un signal d'alerte plus fort qu'un prix élevé.
Sachez qui écrira réellement le code
Les personnes présentes au rendez-vous commercial ne sont souvent pas celles qui construiront votre système. Demandez les noms, les rôles et l'expérience des ingénieurs qui travailleront sur le projet, et demandez à parler au responsable technique avant de signer.
Demandez si une partie du travail est sous-traitée ou confiée à des freelances. Les deux peuvent très bien fonctionner, mais vous devez le savoir, et le partenaire doit se porter garant de chaque personne qu'il fait intervenir. Demandez aussi ce qui se passe si un ingénieur clé part en cours de projet, et qui paie le temps nécessaire à son remplaçant pour se mettre à niveau.
- Qui est le responsable technique, et quelle part de son temps consacre-t-il à ce projet ?
- Quels ingénieurs sont salariés, et lesquels sont sous-traitants ou freelances ?
- Comment sélectionnez-vous et vérifiez-vous les spécialistes que vous faites intervenir ?
- Que se passe-t-il si quelqu'un part ou ne convient pas ?
Demandez des références qui correspondent à votre problème
Une longue liste de clients ne prouve pas grand-chose si aucun projet ne ressemble au vôtre. Demandez des exemples aux contraintes similaires : le même type de système, un trafic ou une sensibilité des données comparable, et un contexte réglementaire proche. Demandez ensuite ce que cette équipe a fait dans chaque cas, et non ce que l'ensemble du programme du client a accompli.
Soyez précis sur l'expérience que vous achetez. Certaines sociétés présentent le parcours individuel de leurs ingénieurs, ce qui est légitime si c'est dit honnêtement. Demandez quand l'entreprise a été créée, quels travaux ont été réalisés sous ses propres contrats, et si vous pouvez parler à un ancien client.
Obtenez par écrit le périmètre, les jalons et les critères de recette
Beaucoup de litiges viennent d'un périmètre qui n'a jamais été écrit précisément. Une bonne proposition nomme les livrables, découpe le travail en jalons et définit comment chaque jalon est accepté, par exemple des tests qui passent, une démo sur un environnement de préproduction ou une documentation livrée.
Demandez comment les demandes de modification sont traitées et chiffrées, et quel est le modèle commercial. Le forfait convient à un travail bien défini, tandis que la régie convient à une phase de découverte et à des exigences qui évoluent. Dans les deux cas, vous devez voir les hypothèses derrière l'estimation.
Réglez la propriété du code et la passation avant de commencer
Le contrat doit préciser que le code et la propriété intellectuelle associée vous appartiennent, et à quel moment la propriété est transférée. Demandez que les dépôts, les comptes cloud et les domaines soient créés dans votre organisation dès le premier jour, le partenaire y étant invité comme collaborateur, pour ne jamais dépendre de lui pour vos accès.
Planifiez la passation dès le début, pas à la fin. Demandez ce que vous recevrez : documentation, dossiers de décisions d'architecture, runbooks d'exploitation et sessions de travail avec votre propre équipe. Vérifiez quelles licences tierces et open source le projet utilisera, car elles s'accompagnent d'obligations.
Convenez de la façon dont vous suivrez l'avancement
Vous ne devriez jamais avoir à demander si le projet est sur les rails. Convenez d'un rythme fixe, comme une démo hebdomadaire d'un logiciel qui fonctionne et un court point écrit couvrant l'avancement, les risques et les décisions attendues de votre part.
Demandez un accès direct à l'outil de suivi des tickets et au dépôt, ainsi qu'un interlocuteur nommé qui répond de la livraison. Clarifiez comment les problèmes sont remontés et dans quel délai vous pouvez attendre une réponse.
Testez leurs pratiques de sécurité, pas leurs badges
Demandez comment les ingénieurs accèdent à vos systèmes et à vos données, comment les secrets sont stockés, comment le code est relu avant sa mise en production et comment les dépendances sont vérifiées contre les vulnérabilités connues. Des réponses concrètes comptent plus qu'une slide remplie de logos.
Si le partenaire traite des données personnelles pour votre compte, il vous faut un accord de traitement des données conforme aux exigences du RGPD. Si un prestataire revendique une certification, demandez le certificat et son périmètre, et vérifiez qu'il couvre l'équipe et les services que vous achetez.
Les signaux d'alerte qui doivent mettre fin à la discussion
Un signal d'alerte isolé peut avoir une explication. Plusieurs à la fois signifient généralement que le projet sera plus difficile que nécessaire.
- Ils ne peuvent pas nommer les ingénieurs qui feront le travail.
- Les études de cas montrent des résultats, mais pas ce que cette équipe a réellement fait.
- L'estimation arrive avant que quiconque ait posé des questions détaillées sur votre système.
- Les dépôts et les comptes cloud restent sous le contrôle du partenaire.
- Les jalons n'ont pas de critères de recette écrits.
- Les questions de sécurité obtiennent des assurances générales au lieu de pratiques précises.
À retenir
- Rencontrez le responsable technique et sachez qui écrira le code avant de signer.
- Jugez les références à leur proximité avec vos contraintes et à ce que l'équipe a elle-même réalisé.
- Des jalons écrits avec des critères de recette clairs évitent bien des litiges sur le périmètre.
- Gardez les dépôts et les comptes cloud dans votre propre organisation dès le premier jour.
- Demandez des pratiques de sécurité précises et des preuves pour toute certification revendiquée par un prestataire.
FAQ
Avec combien de partenaires faut-il échanger avant d'en choisir un ?
Assez pour comparer de vraies différences d'approche, ce qui, pour la plupart des projets, veut dire quelques-uns. Donnez à chacun le même brief et les mêmes questions, pour que les réponses soient comparables.
Faut-il choisir un contrat au forfait ou en régie ?
Le forfait convient à un travail que vous pouvez spécifier en détail avant qu'il ne commence. La régie convient à une phase de découverte, à des exigences qui évoluent et au développement continu, à condition d'obtenir un reporting transparent et des démos régulières.
Que doit couvrir un premier appel avec un partenaire potentiel ?
Votre objectif, vos contraintes, votre calendrier et vos systèmes existants, ainsi que les questions qu'il vous pose en retour. Un partenaire qui pose des questions détaillées sur votre système dès le premier appel est généralement un partenaire qui l'estimera honnêtement. Chez SDK Enterprises, ce premier appel est un échange de 30 minutes, en français ou en anglais.