Cycle de vie d’une application

Cycle de vie d’une application

Tous les jours, nous utilisons des logiciels, des applications ou des sites internet. Ceux-ci peuvent exister depuis plusieurs années, et se sont vus mis à jour plus ou moins souvent, tant techniquement que visuellement.

Pour palier aux problématiques communes, comme des changements de technologies, de main d’œuvre, il existe un grand nombre de théories, de concepts, et de processus pour faire vivre et évoluer ces projets.

Quelles sont ces processus, comment faire le bon choix pour son propre projet, et comment les mettre en place ? C’est ce que nous allons voir aujourd’hui :)

Préparer un projet

Avant d’entamer son cycle de vie, un projet doit d’abord être préparé avec attention. On assume ici que vous avez déjà procéder à tout le traitement du concept derrière le projet, comme évoqué plus tôt dans l’année.

Les documents

Avant quoique ce soit, il est important d’écrire tout ce que vous savez sur votre projet. Cela peut être un ou plusieurs cahiers des charges, des zonings, des analyses, des études ou des prévisions, peu importe. Rassemblez et nomenclaturez tout ce que vous savez.

Vous pourrez reconstituer tout l’historique du projet, ainsi que les raisonnements et réflexions qui vous ont amenés à un instant T. Cela évite de refaire des erreurs ou de reperdre du temps avec une problématique déjà traitée.

N’oubliez jamais que ce qui est évident pour vous ne l’est pas forcément pour les autres. Soyez explicites dans vos documents et demandez des retours à votre équipe régulièrement.

L'image ci-dessous est connue dans le monde de la gestion de projet, ça marche plutôt bien ! :)

Le planning

Tout comme les documents, planifier les différentes étapes de votre projet n’a pas pour vocation à être une science exacte, mais à donner une idée du timing pour toute l’équipe. Cela nécessitera des ajustements en cours de route, mais au moins vous partez avec une idée du temps que va prendre chaque étape.

Estimer des temps de développement est un exercice délicat, et il est bien souvent impossible de se rendre compte du temps que cela va prendre avant d’avoir terminé le travail. Il existe tellement de contraintes et de paramètres différents à chaque fois, qu’approcher le temps estimé est déjà une victoire en soi :)

Les versions

Partie spécifique aux projets qui ont pour volonté de durer indéfiniment : déterminez les limites de chaque version prévue. C’est la principale cause de perte de temps rencontrée lors des développements informatiques : Rajouter des fonctionnalités parce qu’on peut.

Oui, on peut, mais cela prend du temps et créé des problèmes non anticipés, car inscrits nulle part dans les documents rédigés.

A moins qu’une fonctionnalité ne soit strictement et absolument essentielle - et dans ce cas-là, demandez-vous pourquoi elle apparaît subitement sans que personne n’y ait pensé avant - cantonnez vous aux listes établies au préalable.

Un projet informatique a tout le temps d’évoluer, vous rajouterez les fonctionnalités au fur et à mesure des versions, en ayant pris le temps de les insérer proprement dans celles déjà existantes.

Scénarios et jeux d’essais

Avant même le début du projet, que ce soit un site web ou une application, prenez le temps d’établir des scénarios utilisateurs (use-cases) qui vous guideront lors des développements et des phases de test.

De même, vous pouvez intégrer dès à présent des informations qui seront ou qui ressembleront suffisamment aux données finales pour apporter une fiabilité aux phases de recette.

Si vous utilisez un logiciel pour établir vos jeux d’essais, assurez-vous avec les développeurs qu’ils pourront l’exporter ou utiliser un script pour importer les données. S’ils doivent la saisir à la main ou deviner comment la structure fonctionne, ça ne servira à rien. Vous pouvez utiliser Excel ou Airtable pour cela.

Développement du projet

Une fois que nous avons planifié tous les travaux à réaliser, il est temps de se retrousser les manches. Mais comment gérer quand tout ne se passe pas comme prévu ? Comment limiter les pertes de temps et de devoir repenser tout un projet à cause d’un oubli ?

Milestones

Une milestone, comme dans le monde réel, est un point marquant la fin d’une section, d’une étape.

Elles sont prévues à l’avance, encadrant en général une fonctionnalité bien précise, ainsi que ses éventuels branchements aux autres fonctionnalités du projet.

Ces milestones ont également leur place dans le planning, dans un Gantt, pour structurer les interdépendances entre elles. En effet, il est parfois nécessaire d’avoir développé une fonctionnalité avant de pouvoir en développer une autre.

Il est donc important d’avoir un aperçu de cet ordre, notamment visuel, pour les membres de l’équipe les moins techniques. Le fait qu’une fonctionnalité dépende du bon fonctionnement d’une autre n’est pas toujours évident.

A chaque fois que j’ai eu à faire un Gantt, je me suis débrouillé avec GanttProject, un logiciel libre & gratuit. J’ai également entendu parler de ProjectLibre, mais pas encore eu l’occasion de le tester. Un article - en anglais - répertorie également une vingtaine de solutions, incluant les Gantt dans leurs outils.

Par exemple, vous devez avoir terminer la gestion et l’intégration des emails envoyés avant de développer les formulaires de contact qui vont les utiliser.
Parfois, c’est aussi plus complexe, car vous avez besoin de jongler entre deux fonctionnalités pour les faire respectivement fonctionner. Donc vous devez découper les travaux en sous-milestones et avancer sur les deux fonctionnalités en même temps.

Faites ce qui vous semble être le mieux, il n’y a pas de règle universelle et absolue dans ce secteur. Cela dépend des équipes et des méthodes de travail.

Journal de développement & Versionning

Lorsque vous développez un morceau de votre projet, il est important de conserver au maximum possible une trace des actions entreprises.  Aujourd’hui, nous disposons d’outils comme GIT ou SVN pour suivre les modifications effectuées sur un projet.

Même si cela suffit, il est recommandé d’avoir un suivi moins technique de l’avancement des milestones, toujours pour conserver un niveau de compréhension correct pour toute l’équipe. Un template Excel ou l’utilisation d’outils comme Trello, Wimi ou Airtable vont très bien dans ce sens.

Trello
Wimi
Airtable

Ces outils permettent également de découper techniquement des ensembles de codes pour régler des problèmes ou tester des évolutions via leur système de branches.

Ils s’accompagnent aussi de tout un tas de concepts et de scripts d’automatisation bien pratiques que nous aurons l’occasion de parcourir plus tard. :)

Fin du projet

A force de bosser, on arrive forcément au bout du tunnel n’est-ce pas ? Voyons voir maintenant commencer amorcer la sortie d’un projet, vérifier que tout s’est déroulé comme prévu et préparer la suite.

Recette

Une recette consiste à valider un projet ou une milestone. Vous pouvez établir une recette à chaque milestone, ou/et à la fin du projet.

C’est comme vous voulez, selon l’amplitude et la densité du projet.

C’est une phase essentielle du projet. La recette est souvent considérée comme un sous-projet à part entière tant elle nécessite de préparation et de temps pour être réalisée correctement.

Ne sous-estimez pas son importance et répertoriez bien toute recette effectuée.

Tout comme les autres documents de gestion de projet, il n’y a pas de méthode absolue pour effectuer une recette de projet. Basez-vous sur vos documents réalisés avant le début du projet, et vérifiez que chaque étape correspond à ce qui a été prévu, ce qui a été changé et pour quelle raison.

L’idéal est d’avoir réalisé des jeux d’essais et des scénarios au tout début du projet, pour pouvoir ensuite les utiliser dans la recette finale, et s’assurer que les résultats obtenus sont bien ceux prévus.

Mise en production

Une fois tous les travaux et toutes les recettes validées, il est grand temps de profiter de ce dur labeur. On appelle ce processus le déploiement ou la mise en production d’un projet.

Selon le projet, vous allez avoir besoin de choses différentes. Par exemple, pour un projet web, c’est des identifiants FTP ou SQL, pour accéder au serveur. Pour une application, cela va être l’accès aux comptes Google ou Apple.

Tout ce dont vous avez besoin devrait être listé dans un fichier en amont. Pour ne pas se retrouver con une fois le feu vert obtenu. Et ça arrive plus souvent qu’on le voudrait.

Par exemple, on a beau être en 2018, il se peut qu’une propagation DNS, ou une validation de la part d’Apple prenne plusieurs heures ou plusieurs jours.

Ce n’est pas quelque chose que vous pouvez maîtriser, mais vous pouvez plus ou moins anticiper le temps que des actions peuvent prennent.

Faites également un bon paquet de sauvegardes, et de procédures pour mettre en ligne ou pour rétablir une version antérieure. Dans l’urgence, il vaut mieux éviter d’avoir à se souvenir de comment les choses fonctionnent, pour ne pas tout fracasser.

Enfin, faites des packages, datés et nommés en incluant la version du projet, pour pouvoir restaurer une version précise, ou pour l’envoyer aux différentes parties.

Préparer la version suivante

Bon, on a évoqué un cycle, donc il faut bien un moment où on recommence la boucle. On a terminé avec des documents, et bien on va reprendre avec des documents.

Lister les évolutions

Premièrement, listez toutes les évolutions de fonctionnalités, en faisant référence aux versions précédentes de ces fonctionnalités dans les cahiers des charges. L’important ici est de comprendre pourquoi la fonctionnalité nécessite une évolution.

N’ayez également pas peur de revenir sur le fonctionnement complet d’une de vos idées. Parfois, elles semblent parfaites lors d’une première version, et elles ne prennent juste pas.

Cela a été le cas dans un de nos développements, où un annuaire a été développé, qui devait permettre le listing et la recherche ergonomique de sociétés spécialisées. Et bien sans vraiment savoir pourquoi, cette partie a été rechignée par les utilisateurs.
Il fallait donc se rendre à l’évidence : ça marche pas sous cette forme.

Il se trouve que lors de la refonte du site, l’annuaire a été repensé pour être transformé en un bloc de 3 sociétés spécialisées, positionnées après chaque contenu éditorial contextualisé par thématiques. La sélection se fait selon des règles métier déterminées par le détenteur du site et éventuellement le client.
Et bien, malgré l'extrême simplification - en comparaison à la V1 - ce système a reçu de bien meilleurs retours et génère bien plus de contacts prospects.

Votre projet va évoluer, et surtout au début, il est difficile d’anticiper ce qui va marcher de ce qui va faire un flop. La réussite de votre projet peut être dûe à une fonctionnalité peu approfondie car jugée gadget.

La réalité est qu’on ne sait pas. On fait au mieux pour estimer, mais cela reste au final un tir plus ou moins au pif.

Traquez l’utilisation des fonctionnalités de la version courante, récupérez des retours d’utilisateurs, consultez vos logs et vous pourrez extraire ce qui fait l’essentiel de votre idée, du point de vue de vos utilisateurs.

Il existe aujourd’hui des supers outils pour obtenir du feedback d’utilisateurs. Vous pouvez mettre en place des sondages in-app, ou bien via vos réseaux sociaux. Cela permet d’interroger directement vos utilisateurs.

Vous pouvez également établir des heatmaps, des tests A/B, ou des statistiques via Piwik ou Google Analytics. Cela représente un certain temps et budget, qu’il est difficile de trouver dans les petites structures. On n’a pas encore eu l’occasion d’en essayer un en production.

Ce sont des outils qui sont un peu intrusifs toutefois, puisqu’ils impliquent de traquer directement l’activité de l’utilisateur. Même si c’est dans l’intérêt de leur expérience, ça reste un sujet controversé.

Sondage in-app
Facebook Survey

Audit de performances / sécurité / optimisations

Avant d’entamer la réalisation d’une nouvelle version, vous devriez palier aux erreurs de la version précédente.

En effet, malgré les recettes, il se peut que des raccourcis aient été pris, par simplicité ou manque de temps. Cela fonctionne, pas de soucis, mais cela pourrait être fait dans les règles de l’art. On n’a jamais rien construit de durable sur des fondations bancales.

Avec le temps, des failles de sécurité vont également apparaître. Un changement de technologie ou de serveur seront envisagés et vont faire apparaître des problèmes ou des bugs inconnus jusqu’à présent.

Une des solutions à cela est de prévoir une sorte de version intermédiaire, intégrant les changement de structures, et de faire tourner une version isolée de votre projet, qui ne sera accessible que par vous, pour permettre des audits et ainsi lister les soucis.  Une fois les problèmes corrigés, vous pouvez déployer une nouvelle mise à jour sur le support actuel, puis migrer de support, en étant sûr de vos développements.

C'est un peu vieux comme erreur, mais c'est ce qui peut apparaitre quand on met à jour PHP !

Planifier

Encore et toujours le maître mot de la gestion de projet : planifier vos déploiements de version. Il faut du temps pour obtenir des retours, donc assurez-vous de laisser vivre votre projet avant de le modifier encore et encore.

Vous avez différentes méthodes pour faire évoluer votre système :

  • Chaque version est un projet à part entière, avec ses propres documents et son planning, donc vous disposez d’une date de sortie précise.
  • Vous travaillez en flux tendu, sur une sorte de version semi-permanente et dans ce cas là, vous aurez des nouvelles mises à jour mensuelles ou hebdomadaires, selon la taille du projet.

Il y a énormément de choses à dire et à apprendre quand on parle de gestion de projet. Vous trouverez des méthodes pré-faites sur Internet, comme le Scrum ou autres méthodes Agile, qui sont supposées vous aider dans la réalisation de projets informatiques.

La vérité est qu’il n’y a pas vraiment de bonne méthode. Vous devez trouver celle qui est adaptée à votre équipe et à votre projet. Cela dépend même bien plus de vos méthodes de travail en équipe que du projet.

L’essentiel est que tout le monde comprenne les enjeux, et qu’il n’y ait pas de pertes d’informations entre les différents collaborateurs. N’oubliez pas que vous ne faites pas le même métier que votre collègue, l’évidence pour vous n’est pas la sienne, et réciproquement.

Donc assurez-vous que tout le monde ait compris et approuvé chaque document de travail, et votre projet ira jusqu’au bout :)

Dans la même catégorie