Développement logiciel, les clés de la réussite

Tous les projets logiciels sont uniques, mais tous doivent obéir à des principes communs pour être couronnés de succès. Des phases préparatoires à la maintenance post-livraison, en passant par le choix du bon partenaire, nous vous proposons quelques points qu’il est important de garder en vue afin de vous assurer que votre projet de développement arrive à bon port, dans les coûts et délais prévus, et que le produit final réponde pleinement aux attentes de son donneur d’ordre et de ses utilisateurs.

Cerner les objectifs d’affaires

Améliorer la productivité, diminuer les coûts, satisfaire sa clientèle, augmenter les ventes, retenir des clients… La clarification des objectifs d’affaires permettra de correctement guider l’équipe de développement dans l’élaboration d’une stratégie de livraison, la hiérarchisation des requêtes, l’établissement des critères de succès et la définition d’une feuille de route sur le long terme. Elle permet aussi d’apprécier la valeur des composantes d’un projet et le retour sur investissement.

Déterminer le budget

Plus l’écart se creuse entre les ressources disponibles, toujours limitées, et les besoins exprimés dans un projet, plus les chances de réussite diminuent. De là l’importance de connaître en premier lieu son retour sur investissement et de déterminer par la suite le budget. Dans le cas de liquidités restreintes, une option à considérer, lorsque le ROI est positif, est de faire financer votre projet informatique par une institution bancaire. Calculer le ROI doit être un exercice automatique pour tout projet. Il est en effet indispensable aux décideurs pour juger de la qualité de l’investissement. Il faut aussi s’assurer de calculer en étant le plus réaliste possible.

Idéalement, lorsque vous contactez un partenaire technologique, il faut d’emblée que vous lui donniez un budget de départ ; il pourra ainsi très rapidement vous dire si vos attentes sont réalistes ou irréalistes en regard de votre capacité d’investissement. Il peut également vous suggérer des possibilités alternatives. Dans le cas d’un budget inflexible, le dirigeant devra faire des choix. Par exemple : est-ce qu’un logiciel qui répondrait à seulement 80 % des besoins, mais qui rentrerait dans le budget, serait acceptable ? Seul le dirigeant peut en décider.

Définir les attentes

L’expression des attentes est la phase la plus cruciale d’un projet informatique. Et c’est une étape pendant laquelle il faut se méfier des conclusions hâtives. Il faut discuter et analyser chaque point en profondeur avec les différents intervenants concernés. L’objectif est de réaliser un cahier des charges précis et détaillé de la future application. En mode “cascade”, la précision est absolument primordiale, alors qu’en mode “agile”, on parlera plutôt d’une vision détaillée du projet et on s’économisera le temps mis à définir trop méticuleusement des objectifs qui seront peut-être écartés en cours de route.

Cette étape est aussi celle où l’on sépare le superflu de l’indispensable, où l’on hiérarchise les attentes en fonction des objectifs d’affaires, ce qui permet de déterminer ce que serait un produit minimum viable (MVP).

Cette phase peut aussi être réalisée avec la collaboration de son partenaire technique. C’est même souvent recommandable, car cela permet d’établir au plus tôt une compréhension commune du projet, de définir ensemble une stratégie de réalisation et de fonder les assises d’une collaboration de qualité essentielle au bon déroulement du projet.

Choisir son partenaire

Le prix est un facteur important, mais la politique du choix de la plus basse offre est rarement conseillée. C’est un paramètre parmi d’autres dans le choix du bon partenaire. S'il y a des écarts excessifs entre différentes propositions pour un même projet, c'est souvent qu'au moins l'un des soumissionnaires n'a pas réellement compris les efforts de développement ou les défis techniques. Demandez à vos soumissionnaires que l’on vous explique les raisons d’une différence de coût. N’hésitez pas à les questionner sur des points précis afin de tester la crédibilité de leur offre et de s’assurer qu’ils comprennent tous correctement les caractéristiques de votre demande.

Aussi, veillez à ce que votre partenaire partage vos valeurs, que vos cultures d’entreprises soient compatibles. Une bonne affinité et une communauté de vues sont fondamentales pour une collaboration de qualité entre votre équipe et celle de votre partenaire. Cette compatibilité est même essentielle si vous souhaitez créer une équipe hybride, c’est à dire composée de développeurs de votre entreprise et de votre partenaire technique. À cet égard, travailler avec une équipe locale peut être un atout, notamment en ce qui concerne la bonne communication.

Enfin, dans bien des cas, il est recommandable de privilégier un partenaire “agnostique”, c’est-à-dire qui ne vous enferme pas dans un seul choix technologique et qui est en mesure de vous proposer différentes solutions.

Au forfait ou à l’heure

Les projets de développement informatique se font souvent sur une base horaire. Si vous souhaitez un prix forfaitaire, vous devez vous assurer que votre cahier de fonctionnalités est parfaitement détaillé et que vous prévoyez de faire que peu ou pas de changements en cours de mandat. Aussi, votre projet ne doit pas reposer sur des technologies trop nouvelles, plus ou moins expérimentales, les incertitudes devant être minimales. Une technologie solide et éprouvée autorise une bien meilleure visibilité.

Bâtir un logiciel s’apparente à la construction d’une maison. Si vous avez des plans d’architecte suffisamment détaillés, il est possible de déterminer au départ un coût précis. Si vous modifiez les plans en cours de chantier, vous paierez inévitablement des “extras”. Cependant, il faut bien savoir qu’en matière de développement logiciel, il est très rare que le projet n’évolue pas au cours du temps, et plus son envergure est large, plus il est susceptible de connaître des modifications. C’est pour cette raison que la facturation horaire est privilégiée. Celle-ci évite aussi d’éventuelles divergences de vues sur ce qui doit ou ne doit pas entrer dans le cadre du forfait, qui peuvent générer des tensions pendant la réalisation. Elle est particulièrement appropriée pour les projets qui adoptent un cycle de développement itératif, tant qu’elle est jumelée avec un suivi précis des coûts.

Une troisième voie est aussi envisageable : un projet peut comporter des phases bien encadrées qui entrent dans un forfait et d’autres qui seront facturées à l’heure. Cette approche permet de sécuriser une partie du budget tout en se laissant une certaine flexibilité pour laisser place aux besoins émergents.

Identifier les contraintes et gérer le risque

Lorsqu’on a été prévenu de ce qu’on doit craindre ou de ce qu’on doit éviter, on est doublement en état de prendre des précautions ou des mesures. Il faut avoir une bonne conscience des restrictions ou des limitations du projet, qui peuvent être d’origine humaine, matérielle, technologique, budgétaire ou encore temporelle. Les principales contraintes relèvent bien souvent de dépendances à des systèmes externes ; il faut correctement les identifier et s’assurer de n’en oublier aucune.

Tout projet comporte des risques inhérents. Les recenser dès la phase de définition de projet permet de préparer une stratégie pour les circonscrire. Aussi, le client est l’expert de son domaine d’affaires et sa présence à toutes les étapes clés du projet est la garantie d’éviter la plupart des obstacles.

Privilégier le développement itératif

La réalité est qu’un projet informatique d’envergure évolue constamment au cours de son développement et que pour bien réussir, le partenaire doit s’adapter en permanence aux changements de priorités. Ces derniers peuvent être de cause externe, par exemple une modification du marché ou des besoins émergents. Il faut donc une méthodologie qui laisse la place au pragmatisme et à la flexibilité. Les projets d’une certaine taille doivent idéalement être réalisés en mode itératif, c’est-à-dire d’avoir des livrables sur une périodicité fixe. Ces étapes de livraison doivent être l’occasion de rencontrer son partenaire, de constater l’avancement des travaux et de vérifier l’adéquation avec les attentes. Obtenir rapidement des livrables permet de diminuer considérablement le risque d’avoir en fin de parcours un logiciel qui ne répond pas réellement aux besoins. Cela vous autorise à faire sans délai des ajustements, voire à changer la direction de votre projet, en cas d’imprévu.

Adopter les meilleures pratiques

L’adoption par votre partenaire des meilleures pratiques a pour but de parer tout échec ou carence du projet logiciel. Il s’agit en quelque sorte d’une assurance contre les risques inhérents à l’industrie. Dysfonctionnements, interruptions des services et intrusions peuvent avoir de lourdes conséquences financières. Et améliorer la qualité est toujours un gage de performance.

Mettre l’utilisateur au centre. L’expérience vécue par les utilisateurs est primordiale au succès de votre application. Un design cohérent et des interfaces intuitives les aident à obtenir les résultats qu’ils souhaitent et suscitent un meilleur engagement, ce qui garantit une bonne adoption de l’outil et se traduit en augmentation de la productivité et de la satisfaction. Avoir en tête l’utilisateur final et ses besoins tout au long du projet fait partie des bonnes pratiques.

Endiguer la dette technique. Au début d’un projet, on peut avoir tendance à vouloir des fonctionnalités livrées au plus vite aux dépens d’une qualité irréprochable du code. On peut aussi avoir des dates de livraison non négociables qui obligent à prendre temporairement des raccourcis. On accumule ainsi une “dette” qui sera à rembourser tôt ou tard, et comme pour les finances, plus on attend, plus elle grossit. Sur les projets d’envergure, il est impératif de surveiller en continu l’accumulation de cette dette et d’avoir une stratégie de contrôle claire. Différentes méthodes peuvent être mises en pratique comme des sprints dédiés à la dette, une fraction du temps consacré à l’amélioration continue, etc.

Penser qualité… Tout le monde s’entend pour dire qu’un bogue qui est identifié pendant le processus de développement est infiniment moins coûteux que celui qui serait identifié plus tard, par exemple pendant les tests d’acceptation par l’utilisateur ou pire encore, à la mise en production. Les techniques d’intégration continue et une revue du code correctement menée aideront à identifier les problèmes qui, s’ils sont corrigés au bon moment, feront économiser énormément de temps, d’argent et d’énergie. À cet égard, vous devez vous assurer que votre partenaire est en mesure de déployer tous les outils standards de l’assurance qualité qui peuvent être nécessaires à la réussite de votre projet : tests unitaires, d’intégration, d’intégration continue, des interfaces, tests fonctionnels, etc.

Et sécurité. Enfin, il ne faut jamais perdre de vue les enjeux de sécurité et ne jamais tenter d’économiser sur ce chapitre. La prise en compte de la sécurité à toutes les phases du projet fait partie d’une démarche d’assurance qualité globale.

Prise en main

Le succès de l’implantation d’une nouvelle solution, sa bonne adoption par ses utilisateurs, passe souvent par la formation afin que la prise en main soit rapide et efficace. Il est important d’établir dès que possible le type de formation, le niveau de documentation utilisateur attendu et les responsabilités de l’équipe de réalisation ou l’implication d’autres intervenants. Votre partenaire doit être à même d’offrir ce service. De manière générale, plus la solution est complexe, plus ses utilisateurs doivent être accompagnés, autant par des intervenants maîtrisant le nouvel outil que par une documentation claire.

Maintenance

Un logiciel doit être maintenu tout au long de sa vie. Il est important d’avoir un partenaire qui peut vous proposer des services de support et maintenance en postproduction. Ce partenaire doit aussi se montrer proactif afin d’anticiper les problèmes prévisibles comme ceux induits par un changement de version de système d’exploitation. Il est raisonnable de prévoir dès le lancement d’un projet les coûts de maintenance qui s’additionnent à ceux du développement de la solution, et qui doivent être pris en compte dans le calcul du ROI.