Quelles pratiques pour la création rapide d’applications pérennes ?

externaliser-developpement-applications-mobiles-agences-sous-traitance

Quelles pratiques pour la création rapide d’applications web et mobiles pérennes ? Voilà le sujet d’une enquête menée par AxioCode auprès de ses équipes de développement, puis auprès d’équipes de développement d’autres entreprises en mars et avril 2021.

Pourquoi cette question ? La création rapide d’applications serait-elle contradictoire avec leur pérennité : vite fait, mal fait ? A l’inverse, pour qu’une application soit bien conçue et pérenne, faut-il considérer que cela prendra plus de temps qu’il n’en faudrait ?

En fait, nous voudrions les deux : rapidité et pérennité. Que nous fassions partie d’une équipe de développement en agence ou en entreprise, nous voulons produire des applications de qualité, pérennes, en un minimum de temps.

Comment faire pour y parvenir, concrètement ? Nous avons imaginé un outil idéal. Cet outil, un peu magique, permettrait de réaliser des spécifications fonctionnelles plus structurées qu’avec un modèle word ou même un logiciel spécialisé comme Visual Paradigm. La formulation des exigences ferait l’objet d’un contrôle de syntaxe sur la base d’un dictionnaire métier ; elle serait structurée, jusqu’à permettre la génération automatique de code. Les spécifications techniques s’appuieraient sur des bibliothèques de composants réutilisables. Des plans de tests fonctionnels seraient automatiquement générés, et pour les fonctionnalités les plus importantes se traduiraient sous forme de tests fonctionnels automatisés Cypress. Les tickets d’incident ou de support seraient également gérés avec cet outil, leur résolution entraînant si besoin la mise à jour des spécifications et du plan de test. Notre outil idéal assurerait également la gestion de projet, l’organisation et la planification des tâches, la saisie des temps et le suivi de l’avancement des travaux. Il offrirait des fonctionnalités de versionning et de traçabilité. Et bien entendu, il serait collaboratif. Vaste programme !

Alors oui, il existe de nombreux outils qui répondent chacun à une partie de ces besoins. Mais nous pensons que leur intégration dans un même outil se traduirait par un cercle vertueux, en partant des spécifications fonctionnelles jusqu’à la livraison de l’application en production. Cela rendrait possibles des automatisations et des processus d’industrialisation, qui permettraient à la fois de gagner du temps et de gagner en fiabilité. Il serait plus facile de maintenir à jour les spécifications fonctionnelles et techniques, de même que les plans de tests. Cela permettrait de gagner en pérennité.

Pour guider nos choix, nous avons mené une enquête à laquelle 126 personnes ont eu la gentillesse de bien vouloir répondre. En voici les résultats.

Sommaire
 

Quels sont les meilleurs moyens de créer rapidement des applications web et mobiles pérennes ?

Les idées des développeurs qui ont répondu à cette enquête sont nombreuses ! Les maîtres mots : standardisation et automatisation, sur la base de normes, de méthodes et de frameworks éprouvés. A cela s’ajoute la nécessité de spécifications claires et précises, d’une bonne collaboration et d’une bonne communication à toutes les étapes du projet avec, bien sûr, des développeurs compétents : c’est bien le moins ! 

Il est intéressant de noter que la grande majorité des idées émises vont dans le sens d’un renforcement de la qualité et d’une plus grande rigueur à tous les niveaux, ce qui ne correspond pas forcément aux pratiques actuelles, principalement par manque de temps.

Ces pratiques ont fait l’objet de sept questions principales :

  1. Combien d’outils différents utilisez-vous dans votre équipe pour la rédaction des spécifications, la gestion de projet, le suivi des temps passés sur les tâches, la rédaction et l’exécution des plans de tests, la gestion des anomalies et des demandes de changement ?
  2. Lorsque vous commencez le développement d’une nouvelle application, quelle est la qualité des spécifications qui vous sont fournies ?
  3. Quelle est la proportion du code que vous reprenez de projets antérieurs ?
  4. Quelles sont les tâches les plus répétitives sur lesquelles vous aimeriez gagner du temps ? 
  5. Comment sont organisés les tests fonctionnels en général ?
  6. Au fur et à mesure de la maintenance évolutive, est-ce que vous (ou votre équipe) mettez à jour les spécifications fonctionnelles et techniques initiales du projet ?
  7. Est-ce que vous (ou votre équipe) mettez à jour le plan de tests après les corrections d’anomalies ?

Vous trouverez dans les lignes suivantes une synthèse des réponses apportées à l’ensemble des questions, puis une synthèse des réponses apportées à chaque question plus en détail avec les conclusions que nous en tirons pour notre projet d’outil idéal.

Synthèse des réponses

La plupart des développeurs utilisent plusieurs outils, ce qui n’est pas un problème pour la grande majorité d’entre eux. Mieux vaut des outils différents et bien faits plutôt qu’une “usine à gaz”. L’intégration de fonctionnalités variées au sein d’un même outil doit apporter des bénéfices supérieurs aux problèmes que cette intégration peut poser. Pour générer automatiquement du code et des tests, ou pour mettre à jour les spécifications et les tests à partir de la résolution des anomalies, ce sont les outils de spécifications, de tests et de ticketing qui peuvent être intégrés dans un même outil.

La qualité et la complétude des spécifications est un facteur décisif dans la maîtrise des délais et par voie de conséquence dans l’objectif de la création rapide d’applications. Nous pensons que la formulation structurée des exigences peut y contribuer significativement.

Lors du développement d’une nouvelle application, peu de code est repris de projets antérieurs. On procède plutôt par copier/coller que par la mise en place de composants réutilisables, et moins encore par une démarche RAD / Low code. C’est pourtant la direction que prend l’industrie informatique pour faire face aux défis de la digitalisation de l’économie dans son ensemble. Nous pensons que nos outils doivent augmenter en productivité par la production automatisée d’une plus grande partie du code source de base de nos applications.

Toutes les tâches sont citées comme étant les plus répétitives et sur lesquelles les développeurs aimeraient gagner du temps. Cela va de la gestion de projet aux tests, en passant par les spécifications, la mise en place de l’environnement de travail,  l’optimisation du code, le déploiement… etc. L’industrialisation passe par la mise en place de pratiques DevOps, la génération automatique de code, l’usage de composants réutilisables et l’automatisation des tests.

Les tests fonctionnels sont loin d’être systématiques et encore moins automatisés. C’est l’un des problèmes majeurs qui ressort de cette enquête. Pourtant, les tests sont déterminants dans l’objectif de la réalisation d’applications pérennes. Réalisés “manuellement”, ils sont chronophages. Face à cela, la solution passe par l’industrialisation de bout en bout : génération automatique de scénarios de tests à partir des spécifications fonctionnelles, implémentation de tests fonctionnels automatisés, monitoring des applications en production.

Au fur et à mesure des évolutions apportées aux applications, le plus souvent les spécifications sont actualisées. Lorsqu’elles ne le sont pas, c’est principalement par manque de temps ou de budget. Des spécifications qui ne sont pas à jour se traduisent in fine par de la perte de temps. Une solution : il faudrait qu’au travers des outils utilisés, le lien soit fait entre les demandes de changement et les spécifications existantes

Après les corrections d’anomalies, les plans de tests sont mis à jour selon 50% des développeurs. Là encore, c’est le plus souvent par manque de temps que ce n’est pas fait. Cela pose des problèmes de qualité. Un outil intégré de gestion des tickets d’incidents et de tests permettrait de faciliter la mise à jour des plans de tests.

Voyons maintenant plus en détail les réponses apportées à chaque question.

La multiplicité des outils utilisés n’est pas un problème en soi

Question 1 : Combien d’outils différents utilisez-vous dans votre équipe pour la rédaction des spécifications, la gestion de projet, le suivi des temps passés sur les tâches, la rédaction et l’exécution des plans de tests, la gestion des anomalies et des demandes de changement ? 126 réponses :

Dans la plus grande majorité des cas, ce sont au moins deux outils qui sont utilisés.

Chez AxioCode, nous utilisons quatre outils : Visual Paradigm pour la rédaction des spécifications, OpenProject pour la gestion de projet et le suivi des temps passés, Squash TM pour les tests, Gitlab pour la gestion des anomalies et les demandes de changement. Il est probable que le nombre d’outils soit proportionnel à la taille de l’équipe de développement et à la complexité des applications développées. Au démarrage d’AxioCode, nous n’avions pas d’outil spécifique pour les tests (Excel) ou pour les spécifications (Word) ; si l’on ne prend pas en compte les outils bureautiques, nous n’en avions alors “que” deux.

L’utilisation de plusieurs outils plutôt qu’un seul vous pose-t-elle problème ? 108 réponses :

Près des ¾ des développeurs interrogés n’ont pas de problème avec l’utilisation de plusieurs outils.

En quoi l’utilisation de plusieurs outils n’est-elle pas problématique ? 52 réponses :

Il est jugé qu’un seul outil apporterait probablement plus de complexité : mieux vaut plusieurs outils bien faits et répondant chacun à un besoin spécifique qu’une “usine à gaz” à tout faire. En outre, une solution centralisée serait trop problématique en cas d’indisponibilité ou de problème de sécurité. Avec plusieurs outils, il y a une certaine perte de transparence, de clarté et parfois de temps, sans qu’on puisse aller jusqu’à dire que c’est problématique. Et c’est d’autant moins problématique si les différents outils utilisés sont interopérables.

Quel est le principal problème que vous pose l’utilisation d’outils différents ? 30 réponses :

Le principal problème est que les informations sont éparpillées, voire dupliquées. Il est parfois difficile de s’y retrouver et des oublis sont possibles (par exemple la mise à jour d’une exigence sans report sur les tests). La maîtrise correcte d’outils différents n’est pas toujours évidente. La multiplicité des outils représente une perte de temps. 

Nous pouvons conclure sur ce point que l’intégration de fonctionnalités variées au sein d’un même outil doit apporter des bénéfices supérieurs aux problèmes ou aux risques que cette intégration peut poser. Cela sera le cas avec la génération automatique de code à partir de spécifications structurées, avec la génération automatique de cas de tests et de tests fonctionnels automatisés, ou encore avec la mise à jour des spécifications et des tests à partir de la résolution des anomalies. Ce sont alors les outils de spécifications, de tests et de ticketing qui pourront être intégrés. L’intégration des fonctionnalités de gestion de projet semble moins utile.

Les spécifications sont souvent insuffisantes, ce qui fait perdre du temps

Question 2. “Lorsque vous commencez le développement d’une nouvelle application, en général” (126 réponses) les informations fournies sont suffisantes, mais pour à peine plus d’un développeur sur deux. Pour les autres, elles sont souvent incomplètes ou ambiguës. Seul un développeur sur 10 estime que les informations qui lui sont fournies sont exhaustives et rédigées de façon structurée.

Les commentaires associés à cette question indiquent que des spécifications complètes sont moins utiles pour les projets les plus simples. D’autre part, les méthodes agiles sont associées à des scénarios évolutifs avec des changements en cours de développement ; le besoin de spécifications initiales exhaustives est inutile, voire contraire à l’esprit même de ces méthodes : “le produit final doit être déjà une version améliorée du projet de départ”. De même, des spécifications trop volumineuses rendent leur validation difficile par les clients, tout autant que leur lecture ou leur compréhension par les développeurs. 

Développement d'applications : les spécifications ne sont pas assez précises

Quel est le principal problème que vous posent des spécifications insuffisantes ? 49 réponses :

Il s’agit principalement de perte de temps, d’itérations supplémentaires avec le client qui décalent le planning, surtout lorsque le client n’est pas disponible pour répondre aux questions. Plus grave : au-delà du code qui doit être repris et des tests qu’il faut refaire, il est parfois nécessaire de modifier l’architecture de l’application. Cela augmente les temps de développement, les délais de livraison et les coûts. Avec des spécifications insuffisantes, il est difficile d’estimer le temps de travail ; lorsqu’il y a un certain flou, le client peut demander des modifications qui vont rallonger le temps de développement. Le problème est encore plus important quand il y a un intermédiaire entre le client et l’équipe de développement (une agence de communication par exemple) car “il est essentiel de passer du temps avec le client et/ou les équipes métier pour bien définir les besoins et les prioriser”. 

Ces remarques et avis sont très intéressants. Ils appellent les commentaires suivants :

  1. Quelle que soit la méthode, agile ou classique, la qualité des spécifications est déterminante. Les méthodes agiles sont souvent associées à une moins grande rigueur ou tout du moins une moins grande précision des spécifications. Nous pourrions plutôt penser que c’est le moment auquel ces spécifications sont réalisées qui devrait changer par rapport aux méthodes classiques, plutôt que leur qualité ou leur complétude. Quoi qu’il en soit, cela impose au minimum un cadre de départ qui délimite le périmètre fonctionnel.
  2. Les méthodes agiles sont difficilement compatibles avec un développement en sous-traitance, au forfait. Ces méthodes donnent la garantie du délai et du budget, mais pas du périmètre fonctionnel : le client sait ce qu’il paiera et à quelle date il sera livré, mais uniquement pour ce que l’équipe de développement aura eu le temps de coder en fonction des décisions prises de sprint en sprint.

La conclusion que nous pouvons tirer de cette question est que la qualité et la complétude des spécifications est un facteur décisif dans la maîtrise des délais, que la méthode de développement soit agile ou classique. Chez AxioCode, nous sommes certifiés en gestion de projet (Prince 2) et en ingénierie des exigences (Ireb). Nous utilisons Visual Paradigm pour produire les spécifications. Mais les spécifications restent pour l’essentiel du simple texte qui peut être incomplet ou imprécis. Pour aller plus loin dans la qualité de nos spécifications, nous aimerions bénéficier d’outils qui nous aident à formuler de façon structurée les cas d’utilisation et les exigences, avec un contrôle de syntaxe basé sur un dictionnaire des concepts métier du projet.

Article similaire :  8 avantages d'externaliser mon développement web et mobile + 3 conseils

Relativement peu de code est repris de projets antérieurs

Question 3. “Quelle est la proportion du code que vous reprenez de projets antérieurs ?” 126 réponses :

Lorsque du code est repris de projets antérieurs, c’est plus souvent par copier/coller que par la mise en place de composants réutilisables qui impliquent un investissement supérieur en temps : “une simple récupération / adaptation de code source est rapide à mettre en place”.

La démarche RAD / Low Code ne concerne que 3,2% des développeurs qui ont répondu à l’enquête. Pourtant, ces technologies connaissent un regain d’intérêt et les analystes de Gartner, par exemple, prédisent une croissance de ce marché de 22,6% en 2021. L’usage ne se cantonne plus à des besoins périphériques comme la gestion des notes de frais ou des demandes de congés, mais adresse de plus en plus souvent des fonctionnalités métier stratégiques.

La démarche RAD / Low Code semble antinomique avec le développement sur-mesure, du moins du point de vue des développeurs dont c’est le métier de produire du code eux-mêmes. Mais la digitalisation de l’économie dans son ensemble augmente la pression sur les coûts et sur les délais de fourniture de solutions numériques. Par principe, les solutions low code apportent une réponse positive sur cette problématique de coûts et de délais.

Chez AxioCode, nous avons recherché quelle plateforme low code pourrait nous permettre de produire les applications web et mobiles que nous réalisons pour nos clients, et nous n’en avons trouvé aucune. Même s’il est possible d’intervenir sur le code source, ce n’est pas suffisant pour répondre précisément aux besoins.

Pour autant, nous voyons bien que nous re-développons peu ou prou des fonctionnalités qui l’ont déjà été pour d’autres applications. Un framework comme Symfony permet déjà de gagner du temps par rapport à un développement PHP sans framework. En plus de cela, nous développons des bundles qui sont utilisés et améliorés de projet en projet (API, authentification, notifications,… etc.).

Pour aller plus loin dans l’objectif du développement rapide d’applications, nous pensons qu’il est possible d’automatiser la production d’une plus grande partie du code source de base, à partir des concepts définis dans les spécifications fonctionnelles structurées (à l’instar de la pratique éprouvée de production de code Java ou C# sur la base de descriptions UML).

Gagner du temps sur toutes les tâches

Question 4. Quelles sont les tâches les plus répétitives sur lesquelles vous aimeriez gagner du temps ?  126 réponses.

C’est sur l’ensemble de leurs tâches que les développeurs ayant répondu à l’enquête aimeraient gagner du temps : gestion de projet, chiffrage, spécifications, saisie des temps, environnement de travail et DevOps, déploiement, optimisation ou génération automatique de code, développement, revue de code, tests.

Cela semble indiquer que le développement professionnel d’applications est en grande partie artisanal. Au-delà des pratiques DevOps qui se développent, la création rapide d’applications web et mobiles pérennes passe par l’industrialisation des processus les plus consommateurs de temps : génération automatique de code, usage de composants réutilisables, automatisation des tests.

Les tests sont problématiques

Question 5. Comment sont organisés les tests fonctionnels en général ? (plusieurs réponses possibles, 126 répondants)

Un tiers des développeurs interrogés indiquent qu’il n’existe pas de plan de test formalisé. Pour seulement un tiers d’entre eux, un plan de tests est rédigé et utilisé pour l’exécution des tests. Pour 71% des réponses, les tests sont effectués par l’équipe de développement ; il est assez surprenant que ce ne soit pas dans 100% des réponses, même lorsque les travaux portent sur des adaptations d’un ERP ou d’un CRM. Les tests sont exécutés par le client ou les utilisateurs finaux pour 43% des réponses, ce qui est également assez peu.

Seulement 10% des développeurs interrogés précisent que les cas de tests fonctionnels sont générés automatiquement par un outil de gestion des exigences ou de gestion du cycle de vie applicatif.

Les commentaires indiquent que les développeurs, globalement, ne font pas assez de tests pendant le développement, par manque de temps. Le problème est que “cela entraîne des temps de correction disproportionnés.”

La problématique des tests est un des enseignements les plus marquants de cette enquête. Car la création d’applications pérennes implique un niveau de qualité des travaux intimement lié à la qualité des tests réalisés, même pour les projets les plus simples.

Certes, les tests peuvent être chronophages, surtout lorsqu’ils sont réalisés manuellement. Mais une application qui n’est pas correctement testée à chaque évolution présente des risques de régression dont la correction est encore plus chronophage.

La plupart des solutions de gestion des exigences du marché permettent la génération automatique de scénarios de test en fonction des exigences, la génération de cas de test à partir de diagrammes UML et l’intégration avec des outils de tests comme Jira par exemple.

Chez AxioCode, nous utilisons Squash TM pour définir des plans de tests fonctionnels et suivre leur exécution. Nous implémentons également des tests fonctionnels automatisés avec Cypress pour les fonctionnalités les plus critiques et les plus fréquemment utilisées. Nous utilisons Sentry pour monitorer les applications en production et obtenir des rapports d’anomalies. 

Pour aller plus loin dans l’automatisation et l’industrialisation, nous voudrions que les scénarios de tests soient générés à partir des spécifications fonctionnelles, y compris lors des évolutions au fil du temps. Nous aimerions que les corrections d’anomalies permettent facilement d’ajouter des cas de tests.

Mise à jour des spécifications

Question 6. Au fur et à mesure de la maintenance évolutive, est-ce que vous (ou votre équipe) mettez à jour les spécifications fonctionnelles et techniques initiales du projet ? 126 réponses.

Les spécifications fonctionnelles et techniques sont le plus souvent mises à jour au fur et à mesure des modifications apportées à l’application. Pour un tiers des développeurs qui ont répondu à l’enquête, elles le sont rarement (31%) ou parfois jamais (3,2%).

La principale raison pour laquelle les spécifications ne sont pas mises à jour (46 réponses) est le manque de temps ou de budget (55%), ou bien parce que “ce n’est pas vraiment nécessaire” (23%) en particulier lorsque qu’il s’agit d’évolutions mineures “qui entraînent peu de modifications de code”. Pour gagner du temps, il faudrait qu’au travers des outils utilisés, “le lien soit fait entre les demandes de changement et les spécifications existantes”, “un outil adapté pourrait aider à mettre à jour”.

Lorsque les spécifications ne sont pas à jour, est-ce un problème pour vous ? (113 réponses)

Des spécifications qui ne sont pas à jour sont plutôt problématiques (45,1%), voire très problématiques (16,8%). En particulier lorsqu’il faut se replonger dans l’application après quelque temps ou lorsque de nouveaux développeurs doivent intervenir. Lorsque l’on se base sur des spécifications qui ne sont pas à jour, le risque est d’apporter des modifications non pertinentes ou incohérentes, sources d’incompréhensions voire de conflits avec les clients. Il faut “se faire une idée” à partir du code source, avec les risques d’erreurs ou d’oublis que cela comporte. Les erreurs auxquelles cela peut conduire vont parfois nécessiter de refaire ce qui avait été fait. Là encore, cela se traduit par de la perte de temps.

Des spécifications qui ne sont pas à jour ne posent pas de problème pour 3,5% des développeurs,  ou pas vraiment (34,5%). Ils se chargent de les mettre à jour eux-mêmes, ou bien ils considèrent que ce n’est pas nécessaire pour les projets les plus simples (la lecture du code source suffit) ou lorsque les travaux s’inscrivent dans le cadre d’une démarche agile.

Chez AxioCode, nous sommes confrontés à cette problématique de mise à jour des spécifications : les demandes de changement sont le plus souvent analysées dans notre outil de ticketing Gitlab sans être reportées dans les spécifications initiales. En traitant les évolutions avec le même outil que celui dans lequel sont gérées les spécifications, nous pensons que nous pourrions automatiser, ou au moins faciliter la mise à jour des spécifications pour disposer à un seul endroit d’une vision complète des fonctionnalités et des caractéristiques techniques des applications.

Mise à jour des plans de tests

Question 7. Est-ce que vous (ou votre équipe) mettez à jour le plan de tests après les corrections d’anomalies ? 126 réponses

Les réponses à cette question sont très partagées : après les corrections d’anomalies, les plans de tests sont mis à jour selon 50% des développeurs. S’ils ne sont pas mis à jour, c’est là encore par manque de temps (57%) ou parce que ce n’est pas jugé nécessaire (19%). Idéalement, “Un outil central pourrait obliger la personne qui modifie l’exigence à modifier le test correspondant”.

Lorsque le plan de tests n’est pas à jour, est-ce un problème pour vous ? (118 réponses)

Majoritairement, les développeurs estiment qu’un plan de test qui n’est pas à jour est problématique (56%). En termes de qualité applicative, il est regrettable de ne pas pouvoir mesurer la validité des fonctionnalités. Le plan de test perd son utilité s’il n’est pas complet car la conformité de l’application livrée ne peut être assurée. Lorsque cela conduit à reprendre les tests “manuellement”, c’est source d’oublis et de perte de temps. Au final, c’est la maintenabilité de l’application qui en pâtit.

Nous n’échappons pas à cette problématique chez AxioCode, le temps nous manque pour mettre à jour systématiquement les plans de tests. De la même façon que pour la mise à jour des spécifications, nous pensons qu’un outil intégré de gestion des tickets d’incidents et de tests permettrait de faciliter, voire d’automatiser ce travail.

Conclusion

Merci à toutes celles et ceux qui ont répondu à cette enquête !

Leurs réponses nous confortent dans nos objectifs, que l’on peut qualifier globalement “d’industrialisation”. Ils nous éclairent également de façon très utile sur les écueils à éviter, en particulier la réalisation d’un outil excessivement “tout en un”.

À la lumière de tout cela, nous avons décidé chez AxioCode de concentrer nos efforts sur une première phase de génération de code pour Symfony et Angular, à suivre avec l’intégration de fonctionnalités relatives aux spécifications et aux tests. La route est longue, mais elle est belle !

Bonus : infographie

Voici une infographie résumant cette étude. Retrouvez toutes nos infographies sur notre compte Pinterest.

Infographie : Quelles pratiques pour le développement rapide d'applications pérennes ?