Comment choisir une équipe de développement logiciel

Que devez-vous clarifier après l’échec du projet ?

Commencez par une courte analyse en interne. Rassemblez le contrat, l’offre, la documentation technique, les accès, le code, les maquettes et la liste des fonctionnalités promises. Notez ce qui fonctionne réellement, ce qui manque et ce qui ne correspond plus à vos processus.

Ne partez pas du principe que le problème vient uniquement du développement. Un projet échoué commence souvent par un cahier des charges flou, des exigences qui évoluent, l’absence d’un interlocuteur côté client ou la promesse d’un délai ferme sans informations suffisantes. Parfois, le code est bon, mais il n’y a pas d’intégration avec la comptabilité, le stock ne reflète pas la réalité du travail ou les employés ne parviennent pas à utiliser le système.

Préparez une liste de questions concrètes : Qu’est-ce qui a changé pendant le premier projet ? Qui validait les décisions ? Comment les fonctionnalités étaient-elles réceptionnées ? Quand avez-vous compris que le délai ne serait pas respecté ? Aviez-vous accès au code et aux données ? Y avait-il un environnement de test et des sauvegardes ?

Quelles questions poser à l’équipe potentielle ?

La première réunion ne doit pas être une simple présentation du portfolio. Elle doit montrer comment l’équipe réfléchit. Donnez-lui une description du processus que vous souhaitez améliorer, pas seulement une liste de boutons et d’écrans.

• Quelles parties du processus étudieriez-vous avant de proposer une technologie ?
• Comment diviserez-vous le projet en étapes pouvant être testées et validées ?
• Quels risques voyez-vous dès maintenant et comment les vérifierez-vous ?
• Qui sera mon interlocuteur permanent et qui prendra les décisions techniques ?
• Que ferez-vous s’il s’avère, pendant le développement, qu’une fonctionnalité est plus complexe que prévu ?
• Que recevrai-je à la livraison : le code, la base de données, la documentation, les accès et les instructions ?
• Comment les erreurs sont-elles traitées après la mise en production du système ?

La bonne réponse n’est pas forcément la plus technique. Si l’équipe parle uniquement de langage de programmation et de design, sans poser de questions sur les rôles, les validations, la facturation, le stock, l’API et les utilisateurs réels, elle n’a probablement pas encore compris le besoin.

Comment vérifier l’expérience et le portfolio ?

Consultez le portfolio, mais ne vous arrêtez pas aux belles pages d’accueil. Cherchez des projets reposant sur une logique similaire : gestion des demandes, rôles et droits, gestion documentaire, équipes mobiles, paiements, stock, facturation automatique ou interconnexion de plusieurs systèmes.

Par exemple, LiftexPro — ERP pour les entreprises d’ascenseurs associe la planification des inspections, la gestion des bâtiments, une application mobile pour les techniciens et la facturation automatique. C’est plus révélateur pour une équipe chargée de construire un système métier qu’une promesse générale de « plateforme unique ».

Pour les processus sur le terrain, consultez également Ekovat — ERP sur mesure, qui relie les demandes, les fiches d’intervention, la flotte automobile, le stock et les documents. La question n’est pas de savoir si le projet relève de votre secteur. Il s’agit de déterminer si l’équipe a déjà résolu des problèmes d’une complexité comparable.

Demandez à voir une démonstration d’un système opérationnel, pas seulement des captures d’écran. La démo de l’ERP pour le transport international permet de voir les trajets, les chauffeurs, la flotte, les clients, les factures, les dépenses et différentes vues selon les rôles dans l’entreprise. Vous saurez ainsi si le prestataire montre une logique métier réelle ou une simple approche visuelle.

Demandez quelle part de ce qui est présenté correspond à un produit existant et quelle part a été développée spécialement pour le client concerné. Demandez des explications sur votre rôle, les intégrations utilisées et les limites. Ne considérez pas les résultats obtenus pour d’autres clients comme une preuve si l’équipe ne peut pas expliquer son propre travail sur le projet.

Comment évaluer l’approche technique ?

L’approche technique doit partir des processus et des données. Pour un CRM, par exemple, il faut décrire les clients, les affaires, les offres, les tâches, l’historique des échanges et les droits des employés. Pour un ERP, il faut préciser le stock, les ventes, les factures, les rapports, les rôles et les connexions avec d’autres systèmes.

Demandez un schéma des principaux modules et du flux des données. Si la boutique en ligne reçoit une commande, comment celle-ci arrive-t-elle au stock ? Quand le bordereau d’expédition est-il créé ? Comment le paiement est-il enregistré ? Que voit le comptable ? En l’absence de réponse claire, le problème apparaîtra plus tard sous forme de travail manuel et d’erreurs.

Vérifiez comment les intégrations sont planifiées. Une connexion API avec un transporteur, un opérateur de paiement, un système de téléphonie ou un logiciel comptable n’est pas une simple case à cocher dans une offre. Il faut préciser les données, la fréquence de synchronisation, la gestion des erreurs, le renvoi des données et la personne chargée de surveiller la connexion.

Posez des questions sur l’environnement de test, les sauvegardes, les journaux, les droits d’accès et la méthode de mise en production des changements. Pour un système traitant des données personnelles, discutez des personnes autorisées à y accéder, de l’enregistrement des actions et de la restauration du fonctionnement en cas de problème.

Comment savoir si la communication sera efficace ?

La communication ne se mesure pas à la rapidité avec laquelle l’équipe répond avant la signature. Vérifiez comment vous travaillerez après le lancement. Y aura-t-il une réunion hebdomadaire ? Où les tâches seront-elles enregistrées ? Comment validerez-vous le design, le processus et la fonctionnalité terminée ? Comment verrez-vous ce qui est planifié et ce qui est bloqué ?

Désignez de votre côté une personne qui connaît l’entreprise et peut prendre des décisions. Si chaque employé donne des instructions différentes directement aux développeurs, le projet partira dans plusieurs directions. La nouvelle équipe doit disposer d’un canal unique et clairement défini pour les exigences et les changements.

Demandez un exemple de rapport d’avancement. Un bon rapport indique ce qui est terminé, ce qui reste à faire, les questions en attente de décision et les éléments qui influent sur les délais. C’est plus utile qu’un message général indiquant que « le projet avance ».

Comment comparer les délais et le budget ?

Ne comparez pas uniquement les montants finaux. Comparez ce qu’ils couvrent. Une offre peut inclure l’analyse, le design, le développement, la migration des données, les tests, la formation, la mise en ligne et la maintenance. Une autre peut se limiter à la programmation.

Pour le développement d’un logiciel sur mesure, la fourchette budgétaire estimée est de 3 000–29 300 €. Ce qui vous sera proposé dans cette fourchette dépend du nombre de modules, de la complexité des rôles, de la migration des données, de l’application mobile, des intégrations, des tests et du besoin de maintenance continue. Ne comparez pas la limite basse d’une offre avec le périmètre complet d’une autre.

Le délai doit également être associé à un résultat. Au lieu de demander que ce soit « prêt rapidement », demandez un calendrier avec les étapes, les dépendances et les conditions de validation. Si vous retardez la transmission d’un accès, d’un contenu ou d’une décision, le délai doit être modifié de manière transparente.

À quoi doit ressembler le processus de travail ?

1. 01
   Audit de l’ancien projet

   Vous examinez le code existant, la base de données, les accès, la documentation et les fonctionnalités qui n’ont pas encore été développées. La nouvelle équipe indique quelles parties peuvent être réutilisées et lesquelles doivent être reprises pour plus de sécurité.

2. 02
   Description du processus réel

   Vous expliquez comment fonctionnent les ventes, l’entrepôt, la comptabilité, les équipes sur le terrain et la direction. L’équipe traduit ce processus en rôles, états, données, notifications et intégrations.

3. 03
   Périmètre pilote

   Vous choisissez une partie importante, mais limitée, du système. Elle doit être testée dans un scénario réel afin de vérifier si les solutions sont pratiques pour les personnes qui les utiliseront.

4. 04
   Validation par étapes

   Pour chaque fonctionnalité, vous définissez ce que signifie « terminée ». Vous la testez avec des données concrètes, consignez vos remarques et distinguez les défauts des nouvelles idées.

5. 05
   Mise en production et formation

   Vous planifiez la migration, les droits d’accès, les sauvegardes, la formation et la période de suivi. Vous n’arrêtez pas l’ancien fonctionnement avant de savoir comment réagir en cas de problème.

6. 06
   Maintenance et évolution

   Vous définissez un canal pour les demandes, les priorités, la réaction aux erreurs, les mises à jour et le prix des changements supplémentaires. Ainsi, l’étape suivante ne commence pas par une nouvelle recherche de prestataire.

Comment éviter de répéter les erreurs du passé ?

Impliquez les utilisateurs dès avant le début du développement. L’employé de l’entrepôt, le dispatcheur et le comptable ne voient pas les mêmes problèmes que le dirigeant. Une courte démonstration basée sur un scénario réel peut révéler une lacune qu’une longue liste d’exigences ne ferait pas apparaître.

Ne changez pas constamment l’objectif sans évaluer les conséquences. Une nouvelle fonctionnalité peut affecter la base de données, les rôles, les connexions API et le délai. Toute extension du périmètre doit être accompagnée d’une description, d’un prix et d’une indication de son impact sur le planning.

Ne laissez pas tout reposer sur des échanges oraux. Consignez les décisions, les validations et les responsabilités. Précisez dans le contrat la propriété du code, l’accès à l’hébergement et à la base de données, la confidentialité, la réception et les conditions de résiliation.

Enfin, vérifiez à quoi ressemble la maintenance après la mise en production. Pour un site ou un système existant, elle peut inclure les mises à jour, les sauvegardes, les contrôles et les petites modifications ; pour un système ERP ou CRM plus complexe, il faudra assurer la surveillance des intégrations, la gestion des utilisateurs et l’évolution des fonctionnalités.

Quel est le bon choix après un projet qui a échoué ?

La bonne équipe n’est pas celle qui promet d’aller le plus vite et de coûter le moins cher. Elle pose des questions sur votre activité, présente des systèmes similaires, explique les limites et découpe le risque majeur en petites solutions vérifiables.

Avant de signer, vous devez savoir qui travaille sur le projet, ce que vous recevrez à chaque étape, comment les fonctionnalités sont validées, ce qu’il adviendra du code et des données, et à qui vous adresser en cas de problème. Si ces réponses sont claires dès le départ, le risque de reproduire le scénario précédent est nettement plus faible.