Choisir une agence pour développer un logiciel sur mesure

Choisir une agence de développement logiciel commence par une question concrète : quelles preuves demander avant de lui confier un outil dont votre activité dépendra ? Une présentation commerciale ne suffit pas à comprendre qui développera le produit, comment seront traitées les incertitudes et ce que vous récupérerez à la livraison. Le choix doit porter sur une proposition de travail vérifiable, avec des responsabilités et des livrables identifiables.

Ce guide d’Anaska, propose une méthode de sélection du prestataire, sans classement d’agences. Les recommandations de consultation, de comparaison et de pilotage sont des conseils éditoriaux à adapter à votre organisation. L’objectif est de préparer une décision argumentée : retenir une équipe capable d’expliquer ses choix, de montrer son travail et d’organiser la vie du logiciel après son lancement.

1. Définir le problème avant de demander une solution

Commencez par décrire le travail que le futur logiciel doit permettre d’accomplir. Qui intervient ? Quelles informations circulent ? Où apparaissent les erreurs, les attentes ou les ressaisies ? Présentez les difficultés observées sans imposer immédiatement une architecture ou une liste d’écrans. Vous pourrez ainsi demander aux agences de discuter le besoin, au lieu de simplement chiffrer une solution déjà figée.

Exemple fictif : une entreprise souhaite remplacer un suivi d’interventions dispersé entre messages et tableaux. Son besoin prioritaire pourrait être de savoir quelle intervention attend une validation, par qui et pour quelle raison. Une messagerie intégrée ou un tableau de bord sophistiqué ne sont alors que des options à examiner. Cet exemple illustre une démarche de cadrage ; il ne correspond à aucun projet client attesté.

Préparez des parcours représentatifs, y compris leurs exceptions : demande incomplète, validation refusée, utilisateur absent, donnée corrigée après envoi. Joignez des documents anonymisés lorsque cela est possible. Précisez aussi les contraintes connues : systèmes à connecter, matériel utilisé, disponibilité des interlocuteurs et échéance motivée par un événement réel.

Enfin, formulez vos critères de réussite sans inventer de gains futurs. Vous pouvez attendre qu’un utilisateur retrouve une décision et son historique, ou qu’un responsable puisse corriger une affectation. Ces résultats observables serviront à discuter le périmètre et à préparer la réception du logiciel.

2. Construire un dossier de consultation comparable

Adressez aux agences un socle d’informations identique. Il devrait présenter le contexte métier, les utilisateurs concernés, les parcours prioritaires, les interfaces avec les outils existants et les principales inconnues. Séparez ce qui est indispensable au lancement de ce qui peut être différé. Une fonctionnalité souhaitée ne devrait pas devenir implicitement une condition de livraison.

Demandez une réponse organisée selon les mêmes rubriques : compréhension du besoin, questions ouvertes, périmètre proposé, livrables, équipe pressentie, hypothèses de chiffrage et accompagnement après livraison. Cette structure est un conseil de comparaison. Elle vous permet de repérer les différences réelles derrière des propositions commerciales présentées de manière différente.

Rendez également visibles vos propres engagements. Qui donnera accès aux applications existantes ? Qui expliquera les règles métier ? Qui préparera les données et validera les écrans ? Demandez à chaque agence d’indiquer les contributions attendues de votre organisation et les conséquences d’une information indisponible. Un calendrier devient plus lisible lorsque ses dépendances sont explicites.

Si votre besoin comporte une interface web, vous pouvez aussi consulter la catégorie développement web, tout en conservant les exigences propres au logiciel : règles métier, données, intégrations et exploitation. Pour préparer votre consultation, privilégiez un dossier suffisamment précis pour susciter des réponses argumentées, sans chercher à rédiger seul toutes les spécifications techniques.

3. Examiner les livrables d’une phase de cadrage

Lorsque des inconnues importantes subsistent, envisagez une phase de cadrage distincte. Demandez ce qu’elle doit résoudre et ce qu’elle laissera volontairement ouvert. Son intérêt doit pouvoir se lire dans ses livrables : description des parcours, règles métier, inventaire des données, proposition d’architecture, risques identifiés et périmètre de lancement recommandé.

Une maquette permet de discuter l’enchaînement des actions, mais demandez aussi comment seront décrits les comportements invisibles : droits d’accès, contrôles de saisie, notifications, échanges avec les applications existantes. Faites préciser le statut de chaque production. Une maquette destinée à discuter les usages n’engage pas nécessairement le même niveau de détail qu’une spécification prête à développer.

Si une intégration reste incertaine, proposez une vérification ciblée. Dans un exemple fictif, l’agence pourrait examiner si une application existante permet réellement de récupérer les informations nécessaires. Demandez alors une conclusion exploitable : ce qui a été vérifié, dans quelles conditions, ce qui bloque encore et quelles alternatives peuvent être étudiées. Évitez de confondre cette exploration avec une fonctionnalité prête à exploiter.

Convenez enfin de ce que vous pourrez réutiliser à l’issue du cadrage, y compris si vous changez de prestataire. Faites préciser les formats remis et les conditions d’utilisation. Pour décider de poursuivre, demandez une proposition actualisée qui distingue les hypothèses confirmées, les arbitrages restant à prendre et les travaux recommandés.

4. Rencontrer l’équipe qui réalisera le logiciel

Demandez à rencontrer les personnes pressenties pour les responsabilités importantes : compréhension métier, conception technique, développement, qualité et mise en production. Les intitulés de poste comptent moins que la répartition effective du travail. Faites préciser qui sera disponible, qui pourra arbitrer une difficulté et comment seront organisés les remplacements.

Pour examiner une référence, partez de sa proximité avec votre problème. Demandez ce que l’agence a réellement réalisé, quelles contraintes elle a rencontrées et comment elle a traité une difficulté concrète. Une interface ressemblante n’éclaire pas forcément les compétences nécessaires pour reprendre des données ou construire des règles de validation complexes. N’exigez toutefois pas la communication d’informations confidentielles appartenant à un autre client.

Un échange autour d’un scénario métier peut vous aider à apprécier la qualité du dialogue. Présentez une situation ambiguë et observez les questions : l’équipe cherche-t-elle les utilisateurs concernés, les exceptions et les conséquences d’une décision ? Demandez ensuite comment cette discussion serait transformée en travail à réaliser et en critères de validation.

Clarifiez aussi la participation d’éventuels intervenants extérieurs : tâches confiées, interlocuteur responsable et modalités de coordination. Évaluez enfin votre confort de collaboration. Pouvez-vous obtenir une explication compréhensible, signaler un désaccord et savoir qui répondra ? Consignez les engagements utiles dans la proposition, au-delà de la bonne impression laissée par l’entretien.

5. Évaluer les choix techniques et la reprise future

Demandez une justification des choix techniques au regard de votre contexte. L’agence devrait pouvoir discuter les conséquences de sa proposition sur les intégrations, l’hébergement, les compétences nécessaires et les évolutions envisagées. Invitez-la à présenter une alternative crédible, puis à expliquer pourquoi elle privilégie une option. Vous évaluerez ainsi son raisonnement sans devoir devenir spécialiste de chaque technologie.

Examinez les frontières du logiciel : quelles données entrent, quels traitements sont effectués et quels systèmes reçoivent les résultats ? Pour chaque dépendance importante, demandez ce qui se passe lorsqu’elle devient indisponible ou change de fonctionnement. Faites préciser les hypothèses concernant les accès, la documentation et les environnements nécessaires aux échanges.

Abordez tôt la possibilité d’une reprise par une autre équipe. Nous conseillons de demander un inventaire des éléments à remettre : code source, instructions d’installation, paramètres nécessaires, description des échanges et documentation d’exploitation. Précisez les modalités d’accès aux dépôts et aux comptes techniques. Faites examiner les conditions contractuelles d’utilisation et de transfert selon votre situation.

La sécurité de fabrication mérite également une discussion. La spécification SLSA version 1.0 décrit une progression de la sécurité de la chaîne de production logicielle et des formats d’attestation, dont la provenance. Cette version est signalée comme retirée sur sa page. Utilisez cette référence pour questionner la traçabilité des livraisons, sans attribuer un niveau SLSA à une agence sans preuve.

6. Comparer les devis poste par poste

Sans périmètre équivalent, deux montants ne permettent pas de départager les propositions. Demandez de distinguer le cadrage, la conception, le développement, les intégrations, la reprise des données, les vérifications et la mise en service. Faites également préciser les dépenses récurrentes envisagées et les prestations exclues. Aucun tarif de marché n’est avancé ici : votre comparaison doit reposer sur les offres effectivement reçues.

Pour chaque ligne, relevez l’unité de facturation, la devise, le traitement des taxes et les conditions associées. Faites expliciter les hypothèses qui pourraient modifier le montant. Si une proposition repose sur du temps de travail, demandez comment sa consommation sera suivie. Si elle porte sur un périmètre défini, examinez comment les demandes nouvelles seront distinguées des corrections.

Utilisez cette grille pour demander des précisions écrites. Une ligne absente appelle une question ; elle ne prouve pas que la prestation est incluse. Demandez enfin comment seront présentés les arbitrages si le périmètre souhaité dépasse votre enveloppe : report d’une fonction, simplification d’un parcours ou investigation préalable.

7. Vérifier le pilotage derrière la méthode annoncée

Une méthode annoncée doit se traduire en pratiques observables. Demandez comment seront organisés les priorités, les décisions, les démonstrations et le suivi du travail restant. Faites préciser votre rôle : quelles réunions nécessitent une décision métier, quels documents devez-vous valider et qui peut accepter un changement de périmètre ?

Si l’agence propose Scrum, le Scrum Guide de novembre 2020 décrit notamment un Product Owner responsable de la gestion efficace du Product Backlog, une équipe qui produit un incrément et une inspection des résultats avec les parties prenantes. La Sprint Review y est présentée comme une séance de travail permettant d’adapter la suite. Demandez comment ces responsabilités et ces échanges seront concrètement organisés.

Choisissez un interlocuteur interne capable de réunir les avis métier et de faire arbitrer les désaccords. Nous conseillons de tenir un relevé partagé des décisions : demande examinée, choix retenu, conséquences et point restant ouvert. Demandez à l’agence de distinguer les fonctionnalités terminées, celles encore en vérification et celles simplement commencées.

Préparez aussi le traitement d’un imprévu. Dans un exemple fictif, une interface externe devient indisponible pendant le développement. Qui analyse les options ? Qui décide d’attendre, de contourner ou de modifier le périmètre ? Faites décrire ce circuit avant le lancement. Vous pourrez alors comparer la clarté du pilotage proposé, au-delà du vocabulaire méthodologique.

8. Transformer la qualité, la sécurité et l’accessibilité en preuves

Demandez un plan de vérification relié à vos parcours : fonctionnement attendu, cas d’erreur, droits d’accès et échanges avec les systèmes existants. Faites préciser qui prépare les scénarios, qui les exécute et comment les résultats sont consignés. Pour les besoins de performance, décrivez les situations à examiner et convenez de conditions d’évaluation représentatives.

Pour une application web, l’OWASP ASVS fournit une base de vérification des contrôles techniques de sécurité et des exigences de développement sécurisé. Demandez quelles exigences seraient retenues et quels résultats seraient remis. OWASP recommande d’inclure la version dans les références aux exigences, car leurs identifiants peuvent évoluer. La simple mention du référentiel ne démontre pas la sécurité du logiciel livré.

Élargissez la discussion à l’exploitation. Le guide d’hygiène informatique de l’ANSSI, publié le 23 janvier 2017, présente un socle de mesures pour sécuriser le système d’information. Comme conseil de sélection, demandez qui prendra en charge les accès, les sauvegardes, les mises à jour et les incidents. Faites distinguer les prestations de l’agence des responsabilités conservées en interne.

Pour l’accessibilité web, les WCAG 2.2 du W3C proposent des critères de succès testables et envisagent une combinaison d’évaluations automatisées et humaines. Définissez les parcours, la cible et les preuves attendues. Demandez notamment comment seront examinés les formulaires et l’utilisation au clavier. Cette recommandation de consultation ne préjuge pas des obligations juridiques applicables à votre organisation.

9. Préparer la réception, les données et la mise en service

Organisez la réception avant la fin du développement. Pour chaque parcours prioritaire, convenez du résultat attendu, des données nécessaires et de la personne qui pourra le valider. Décrivez aussi les écarts qui empêcheraient l’ouverture aux utilisateurs et ceux qui pourraient être traités ultérieurement, selon des conditions acceptées. Faites formaliser ces modalités dans les documents du projet.

Si des données doivent être reprises, demandez un scénario complet : extraction, préparation, transformation, import et vérification. Identifiez les cas à arbitrer, comme les doublons ou les informations incomplètes. Dans un exemple fictif, une ancienne fiche sans responsable doit-elle être importée telle quelle, corrigée ou écartée ? Cette décision relève du métier et mérite d’être prise explicitement.

Demandez un déroulé de mise en service indiquant les intervenants, les validations attendues et la conduite à tenir en cas de difficulté. Faites préciser comment seront préparés les comptes utilisateurs, les accès aux services et l’assistance au démarrage. Un exercice de livraison sur un environnement prévu à cet effet peut être proposé pour examiner les étapes avant l’ouverture.

Incluez la transmission aux personnes qui utiliseront et administreront le logiciel. Préférez des supports adaptés aux tâches : réaliser une opération courante, traiter une erreur, gérer un accès ou contacter l’assistance. Demandez ce qui sera remis, sous quel format et comment ces documents seront actualisés après une évolution.

10. Décider avec les preuves, puis organiser la continuité

Avant de retenir une agence, rassemblez les réponses encore dispersées : proposition, précisions obtenues, livrables annoncés, exclusions et responsabilités. Distinguez les points essentiels pour votre projet des préférences secondaires. Vous pouvez comparer chaque candidature selon la compréhension métier, l’équipe proposée, la transparence du devis, les vérifications prévues et les conditions de reprise. Cette grille constitue une aide à la décision, sans valeur de classement universel.

Pour chaque critère, notez la preuve disponible et la question restante. Une incertitude critique ne devrait pas disparaître derrière une bonne appréciation générale. Si l’intégration centrale n’a pas été examinée ou si l’équipe reste indéterminée, demandez une réponse avant de vous engager sur la réalisation correspondante. Faites examiner les engagements contractuels lorsque leur portée nécessite un avis adapté.

Organisez ensuite la continuité : interlocuteur après lancement, canal de signalement, conditions d’intervention, suivi des corrections et traitement des évolutions. Demandez comment seront distingués la prise en compte d’une demande, son diagnostic et sa résolution. Précisez également le devenir des accès et de la documentation en cas de changement d’équipe.

Vous pourrez alors expliquer votre choix par des éléments concrets : besoin compris, périmètre partagé, responsabilités identifiées et livrables vérifiables. Pour comprendre le cadre éditorial d’Anaska, consultez sa méthodologie. Si votre dossier est prêt, vous pouvez déposer un projet en reprenant les parcours prioritaires, les contraintes et les questions que vous souhaitez résoudre avec le prestataire.