Que mettre dans un appel d'offres de développement logiciel (et les 5 clauses qui vous protègent)

Une demande de proposition (RFP) de développement logiciel est le document qui indique aux fournisseurs ce dont vous avez besoin, pourquoi et comment leurs offres seront jugées. Un bon contient cinq éléments : le problème commercial et les objectifs (pas une liste de souhaits de fonctionnalités), les contraintes connues (fourchette budgétaire, délais, systèmes existants, conformité), une portée claire avec ce qui entre et ce qui sort, les critères d'évaluation par rapport auxquels vous obtiendrez réellement un score et les conditions contractuelles qui régiront le travail. La dernière partie est la plus importante et c’est celle que la plupart des appels d’offres laissent en suspens. Cinq clauses vous protègent : propriété de la propriété intellectuelle, critères d'acceptation, transfert et documentation, contrôle des modifications et assistance post-lancement. Insérez-les dans la demande de propositions elle-même, et non dans le contrat que vous négociez après avoir déjà choisi, et vous gardez vos options ouvertes tant que vous les avez encore.

Que contient un bon appel d'offres pour le développement de logiciels ?

La structure est simple. La discipline consiste à s’en tenir aux résultats et non aux solutions.

1. Le problème et l'objectif. Décrivez ce qui est cassé ou manquant et à quoi ressemble le succès en termes simples. Un bon vendeur propose la construction ; vous décrivez le résultat. Si vous spécifiez la solution en détail, vous saurez seulement s'ils peuvent suivre les instructions.
2. Contraintes et contexte. Fourchette budgétaire, calendrier, systèmes avec lesquels il doit s'intégrer, données qu'il touchera et éventuelles obligations réglementaires. Cacher le budget fait perdre du temps à tout le monde et produit des offres que vous ne pouvez pas comparer.
3. Portée, explicite des deux côtés. Énumérez ce qui est dedans et, tout aussi important, ce qui est de dehors. La plupart des différends commencent par l’écart entre ce qu’une partie pensait être inclus et ce que l’autre ne l’était pas.
4. Critères d'évaluation. Indiquez comment vous noterez les propositions : expérience pertinente, approche technique, équipe, prix et conditions ci-dessous. Les vendeurs écrivent en fonction de ce que vous mesurez.
5. Les clauses de protection. Les cinq ci-dessous. Les inclure dans la demande de propositions, et non dans le contrat ultérieur, est la principale chose qui sépare un acheteur qui garde le contrôle de celui qui ne le fait pas.

C'est également le document dans lequel la décision créer ou acheter un logiciel devrait déjà être prise. Un appel d'offres concerne une construction. Si vous êtes toujours en train de peser des produits disponibles dans le commerce, résolvez ce problème en premier.

Quelles sont les 5 clauses qui vous protègent dans un appel d'offres logiciel ?

Ce sont les termes qui décident qui détiendra le pouvoir une fois le projet terminé. Demandez-les dès le départ, alors que plusieurs fournisseurs veulent encore le travail.

Clause	Ce qu'il sécurise	Qu'est-ce qui ne va pas sans cela
Propriété de la propriété intellectuelle	Vous possédez le code source, les actifs et le droit de les modifier	Le fournisseur est propriétaire du code et vous lui restituez une licence pour votre propre système
Critères d'acceptation	Un test objectif pour "terminé" avant le paiement final	Argument sans fin pour savoir si le travail répond aux spécifications
Remise et documentation	Code, informations d'identification et documents permettant à une autre équipe de prendre le relais	Vous êtes enfermé parce qu'eux seuls comprennent comment cela fonctionne
Changer le contrôle	Un processus et un taux convenus pour les modifications de portée	Factures surprises, ou refus de s'ajuster au fur et à mesure de vos apprentissages
Assistance et maintenance	Délais de réponse et coûts définis après le lancement	Un système opérationnel sans que personne ne soit obligé de le réparer

Pourquoi la propriété intellectuelle appartient-elle à la demande de propositions et non au contrat ?

Parce que l’équilibre des pouvoirs change dès que vous choisissez un fournisseur. Avant de signer, vous disposez de plusieurs parties intéressées et d’une comparaison claire. Après avoir signé, vous disposez d’un fournisseur et d’un système à moitié construit que vous ne pouvez pas facilement déplacer. Une clause qui ne coûte rien à accepter dès la première semaine peut coûter une renégociation ou une reconstruction au cours du sixième mois.

La propriété intellectuelle en est l’exemple le plus clair. Indiquez clairement que tous les codes sources, les actifs de conception et les éléments associés deviennent votre propriété contre paiement, sans qu'aucune licence résiduelle ne soit requise pour les exécuter ou les modifier. Les entreprises réputées acceptent cela sans friction. Un fournisseur qui résiste, parce qu'il veut conserver votre code, vous dit quelque chose d'utile avant que vous ayez dépensé quoi que ce soit.

L'acceptation est la deuxième clause que les gens regrettent d'avoir ignorée. Définissez ce que signifie « terminé » en tant que test que le système réussit ou échoue, convenu à l'avance. Sans cela, les dix pour cent restants d’un projet deviennent une négociation plutôt qu’une livraison, et votre paiement final est le seul levier restant pour forcer l’achèvement.

Comment le transfert de responsabilité, le contrôle du changement et l'assistance vous permettent-ils de garder le contrôle ?

Ces trois décident si vous possédez un système ou si vous louez simplement l'accès aux personnes qui l'ont construit.

Le transfert est une propriété devenue réalité. Le contrat doit exiger un code source fonctionnel dans un référentiel que vous contrôlez, des instructions de déploiement, une configuration de l'environnement, des informations d'identification et une documentation suffisamment bonnes pour qu'une équipe compétente qui n'a jamais vu le projet l'exécute et l'étende. Demandez-le comme un livrable avec sa propre étape d'acceptation, et non comme une courtoisie à la fin. Si le transfert est vague, vous êtes bloqué, peu importe ce que dit la clause IP, car dans la pratique, personne d'autre ne peut toucher au système.

Le contrôle des modifications protège les deux côtés. Vos besoins évolueront au cours de la construction ; c'est normal. Ce que vous voulez, c'est une manière convenue de le gérer : comment un changement est demandé, comment il est tarifé et à quel taux. Le but n’est pas d’empêcher le changement mais d’en éliminer toute surprise, de sorte qu’une nouvelle exigence se transforme en une petite conversation prévisible plutôt qu’en un différend.

Le support et la maintenance sont la clause du lendemain du lancement, c'est-à-dire le moment où le logiciel commence réellement sa vie. Définissez ce qui se passe en cas de panne : les délais de réponse, qui est responsable, combien cela coûte et pendant combien de temps. Un système opérationnel sans obligation de maintenance est un handicap en attente de son premier incident. C’est aussi là qu’apparaît la différence entre un conseil d’achat et un achat de résultat. Un partenaire qui reste responsable une fois le système en production est une proposition différente de celui qui disparaît lors du transfert.

Le point pratique à retenir

Considérez la demande de propositions comme l'endroit où vous fixez les conditions, et pas seulement l'endroit où vous décrivez le travail. Les cinq clauses (propriété IP, acceptation, transfert, contrôle des modifications, support) ne coûtent presque rien à accepter alors que les fournisseurs sont toujours en concurrence et il y a beaucoup à ajouter une fois que l'une d'entre elles a été choisie. Écrivez-les tôt, évaluez les propositions et vous gardez le contrôle du système que vous payez pour construire. Si vous souhaitez avoir une deuxième paire d'yeux sur un mémoire avant qu'il ne soit publié, dites-nous ce que vous construisez ; c'est le genre de cadrage par lequel commence de toute façon notre travail en logiciel personnalisé.