Les questions à poser avant de faire bâtir un logiciel
La plupart des gens qui embauchent un développeur n’ont aucun moyen de distinguer un bon d’un mauvais, alors ils comparent la seule chose qu’ils comprennent : le prix. Ces huit questions sont un meilleur filtre. Elles n’ont rien de technique, vous n’avez pas besoin de comprendre les réponses en détail, et vous pouvez toutes les poser dès la première conversation.
Il arrive un moment, habituellement un an ou deux après un projet, où une organisation découvre ce qu’elle a réellement acheté. Le développeur est passé à autre chose. Personne ne connaît le mot de passe du domaine. Les données sont dans un système qu’une seule personne comprenait, et cette personne ne répond plus à ses courriels.
La cause habituelle, ce sont des questions que personne n’a posées au départ, parce qu’au départ tout le monde parle de fonctions et personne ne parle de ce qui arrive ensuite. Les questions ci-dessous sont celles qui déterminent si vous possédez quelque chose ou si vous le louez à une personne.
1.À qui appartiendra le code une fois le travail terminé?
C’est la question que les gens croient inutile de poser, et c’est celle qui cause les surprises les plus coûteuses. Payer quelqu’un pour bâtir quelque chose ne vous en rend pas automatiquement propriétaire. À moins qu’un contrat ne prévoie le transfert de la propriété intellectuelle, la personne qui l’a écrit peut encore en être propriétaire, et vous pourriez ne détenir qu’une simple permission de l’utiliser.
Vous voulez la réponse par écrit, dans l’entente, avant le début des travaux. Un oui verbal en réunion ne tiendra pas plus tard.
Une bonne réponse ressemble à
Il vous appartient. L’entente vous cède la propriété intellectuelle au paiement final, et vous recevez le code source dans un dépôt que vous contrôlez.
Méfiez-vous si vous entendez
Ne vous inquiétez pas de ça, ou nous gardons le code mais vous pouvez l’utiliser, ou une promesse de régler ça plus tard. Plus tard, c’est après que vous avez payé.
2.Au nom de qui sont le domaine et les comptes?
Votre nom de domaine est l’actif le plus important de toute l’entente, et il est régulièrement enregistré au nom du développeur parce que c’était plus simple ainsi le premier jour. Il en va de même pour le compte d’hébergement, le service de courriel, l’analytique et tout ce dont le projet dépend.
Si votre domaine se trouve dans le compte de quelqu’un d’autre, vous ne contrôlez ni votre propre courriel ni votre propre site web, et le récupérer dépend entièrement de sa bonne volonté et de sa disponibilité. Demandez la liste de tous les comptes que touche le projet, et le nom inscrit sur chacun.
Une bonne réponse ressemble à
Le domaine est enregistré au nom de votre organisation, facturé à vous, et c’est vous qui détenez l’accès. Nous sommes ajoutés comme utilisateurs, et vous pouvez nous retirer.
Méfiez-vous si vous entendez
Nous nous occupons de tout ça pour vous. Pratique le premier jour, et la raison pour laquelle des gens perdent leur propre domaine le cinq-centième jour.
3.Comment puis-je récupérer mes données?
Tout le monde dit que c’est possible. Demandez comment, et demandez qu’on vous le montre. Il y a une grande différence entre un bouton qui exporte un tableur réellement utilisable et une possibilité technique qui exige d’embaucher quelqu’un pour extraire les données d’une base de données.
Posez aussi une deuxième question : qui peut lire vos données, et dans quelles circonstances. Si le système contient des renseignements sur des membres, des clients, des patients ou des donateurs, vous en êtes responsable, peu importe qui a bâti le logiciel.
Une bonne réponse ressemble à
Il y a une fonction d’exportation dans le produit, la voici, voici le fichier qu’elle produit. Seuls votre équipe et l’application peuvent lire les données, et voici qui, de notre côté, peut les lire et quand.
Méfiez-vous si vous entendez
Bien sûr que vous pouvez exporter, sans pouvoir vous le montrer. Ou un devis pour le travail de récupération de vos propres renseignements.
4.Combien coûte le fonctionnement après la construction?
Un projet a un prix et tout le monde en discute. Le faire fonctionner a aussi un prix, et on le découvre souvent plus tard : l’hébergement, le domaine, le courriel, les sauvegardes, les mises à jour de sécurité et les heures quand quelque chose doit être réparé.
Un logiciel vit sur Internet, où tout ce qui l’entoure change sans cesse, et ce qui n’est jamais mis à jour devient peu à peu risqué à exploiter. Demandez le montant mensuel dès la première conversation, et considérez une réponse vague comme un chiffre que vous découvrirez à vos dépens.
Une bonne réponse ressemble à
Voici le prix du projet, voici le montant mensuel, voici exactement ce que couvre le montant mensuel, et voici ce qui serait facturé à part.
Méfiez-vous si vous entendez
L’hébergement est pratiquement gratuit, ou nous verrons pour le soutien le moment venu.
5.Que se passe-t-il quand ça brise un vendredi soir?
Tout finit par briser un jour. Ce qui compte, c’est qui vous appelez et ce à quoi vous pouvez raisonnablement vous attendre.
Vous n’avez pas besoin d’un soutien jour et nuit, et vous devriez vous méfier d’une petite entreprise qui en promet un. Il vous faut une réponse honnête sur les délais de réponse, et vous devez savoir si quelqu’un surveille le système ou si la première alarme, c’est vous qui remarquez le problème.
Une bonne réponse ressemble à
Voici comment nous joindre, voici le délai de réponse que nous visons, et voici ce qui est surveillé automatiquement, si bien que nous le savons souvent avant vous.
Méfiez-vous si vous entendez
Écrivez-moi quand vous voulez. Chaleureux, sincère, et impossible à faire respecter quand cette personne est en vacances.
6.Un autre développeur pourrait-il reprendre le projet?
Vous pouvez poser cette question sans avoir l’intention de partir. La réponse vous indique si le projet a été bâti pour être entretenu ou pour vous rendre dépendant.
Un système bâti sur des technologies ordinaires et répandues peut être confié à quelqu’un d’autre. Un système bâti sur une configuration privée inhabituelle, sans documentation, ne peut être entretenu que par la personne qui l’a bâti, et c’est une position commerciale plutôt que technique.
Une bonne réponse ressemble à
Oui. Il utilise des outils courants, le code est dans votre dépôt, et une documentation explique comment l’exploiter et le déployer.
Méfiez-vous si vous entendez
Personne d’autre ne le comprendrait vraiment. Entendez-y une description de votre position, et aucun compliment sur le travail.
7.Qu’est-ce que vous choisissez délibérément de ne pas bâtir?
Cette question vous dit si vous parlez à quelqu’un qui réfléchit ou à quelqu’un qui dit oui à tout. Quiconque accepte toutes les fonctions dès la première rencontre n’écoute pas, ou prévoit de facturer la différence plus tard.
Une bonne réponse remettra en question quelque chose que vous avez demandé. C’est bon signe : l’indication la plus claire que la personne pense à ce que vous utiliserez vraiment plutôt qu’au montant de la facture.
Une bonne réponse ressemble à
Vous avez demandé ces cinq choses. Vous n’en utiliserez pas deux, et voici pourquoi. Commencez par trois, voyez comment ça se passe, ajoutez le reste si vous le voulez encore.
Méfiez-vous si vous entendez
Oui à tout, sans hésitation, sans aucune question sur votre façon de travailler aujourd’hui.
8.Que se passe-t-il le jour où nous cessons de travailler ensemble?
Posez-la clairement, tôt et sans vous excuser. C’est une question légitime à poser à n’importe qui, et la plus utile de la liste, parce qu’elle oblige chaque réponse précédente à devenir concrète.
Vous voulez entendre la description d’une passation : ce que vous recevez, sous quelle forme et en combien de temps. Une personne qui y a réfléchi a bâti en conséquence. Une personne qui n’y a pas réfléchi vous dit quelque chose d’important sur ce qui vous resterait entre les mains.
Une bonne réponse ressemble à
Vous gardez le domaine et les comptes, puisqu’ils sont déjà à vous. Vous recevez le code, les données et la documentation. Voici environ combien de temps prend une passation.
Méfiez-vous si vous entendez
Un silence gêné. Tout ce que vous devez savoir se trouve dans ce silence.
À quoi ressemble une réponse franche
Il serait un peu fort de publier cette liste sans y répondre nous-mêmes, alors voici nos réponses à nos propres questions.
Le code vous appartient. Le domaine et les comptes sont enregistrés à votre nom, facturés à vous, et vous pouvez nous en retirer. Vos données peuvent être exportées depuis le produit, et elles ne servent jamais à entraîner l’IA et ne sont jamais vendues. Vous recevez un prix de projet et un prix mensuel par écrit avant de vous engager, avec les coûts des tiers présentés séparément des nôtres, pour voir ce que vous paieriez de toute façon et ce que vous nous payez. Nous ne vous promettons pas une place dans les résultats de recherche, parce que personne ne peut honnêtement le faire. Si vous partez, vous gardez tout, et nous vous aidons à tout déplacer.
Nous ne sommes pas non plus la bonne solution pour tout le monde. Si un tableur et un formulaire suffisent vraiment à ce que vous faites, c’est ce que nous vous dirons, et poser la question ne vous coûte rien.
Vous songez à un projet?
Dites-nous ce que vous essayez de régler. Si c’est plus petit que vous le pensez, nous vous le dirons.
Entamer la conversationUne dernière chose
Imprimez les huit questions et posez-les à toutes les personnes que vous envisagez, y compris nous. Les réponses différeront davantage que les devis, et c’est dans ces différences que se cache le vrai coût d’un projet.