shutterstock_204621400

Avez-vous l’impression d’être dépassé par les nouvelles technologies? Nous vivons dans un monde où l’environnement technologique est en constante évolution. On est loin du temps où on pouvait investir dans un système informatique et le garder tel quel pendant plusieurs années. Avec l’arrivée des téléphones intelligents, des tablettes et des lunettes de réalité virtuelle (ex. : Google Glass), ce qui fonctionnait très bien sur notre vieil ordinateur n’est plus suffisant. Les clients en veulent plus. En plus des nouveautés technologiques, nos gentils fournisseurs de systèmes d’exploitation font la course pour en faire toujours plus. Tous les deux ans environ, Microsoft nous en propose une nouvelle version. Comment faire pour ne pas rester derrière?

Pourquoi changer si ça fonctionne?

shutterstock_185325812

Votre entreprise doit constamment s’adapter au marché pour demeurer concurrentielle; vos logiciels aussi. On pourrait croire, à tort, que vos logiciels vont toujours combler vos besoins, mais ce n’est habituellement pas le cas. À propos de ça, il est justement important de faire la différence entre un logiciel acheté tout fait et un logiciel sur mesure. Dans le cas des logiciels tout faits, la seule façon d’évoluer est d’acheter la plus récente version. Même si les fabricants font de grands efforts pour limiter les impacts d’une migration, il y a souvent des problèmes de compatibilité. Certaines fonctions peuvent être touchées par les mises à niveau. De plus, vous devez vous adapter à la vision du fabricant. Si celui-ci change la façon de faire les choses, vous en subissez les effets. Pour le logiciel sur mesure, c’est une autre affaire. Au lieu de passer radicalement d’une version à l’autre, le changement peut se faire plus en douceur. Nous verrons comment plus loin dans le billet.

La peur du changement

J’entends souvent les craintes des clients relativement au changement de leurs logiciels. Plusieurs raisons sont évoquées, par exemple : Est-ce que je vais perdre l’investissement fait dans le logiciel actuel? Est-ce que le nouveau logiciel sera vraiment meilleur? Est-ce que je vais devoir entrer mes données à nouveau? Est-ce que les utilisateurs vont s’y retrouver? Prenons ces questions comme point de départ.

Rentabiliser votre investissement logiciel

Votre logiciel sur mesure a été écrit à partir de vos besoins. Une grande quantité de temps et d’efforts a été nécessaire pour en faire ce qu’il est aujourd’hui. Il faut conserver à tout prix cet investissement et y intégrer vos nouveaux besoins. La beauté avec le développement logiciel, c’est qu’il est relativement facile pour un expert d’en extraire le fonctionnement et de le reproduire, voire de l’améliorer. Depuis le moment où il a été écrit, plusieurs nouvelles technologies ont vu le jour et de nouvelles techniques se sont développées. Même si vous avez une documentation exhaustive sur vos processus d’affaires, il y a fort à parier que votre logiciel les connaît encore mieux. De plus, il n’est pas rare de voir la documentation désuète dès les débuts du développement du logiciel. Une documentation qui n’est pas à jour est souvent pire que de ne pas en avoir du tout. Elle cache des vérités et ne représente pas la réalité. Elle peut même mener à prendre de mauvaises décisions. Quand j’ai à comprendre un logiciel, la documentation originale me donne une bonne idée de l’intention. Toutefois, c’est le code qui me donne l’information la plus juste sur la façon dont le logiciel fonctionne.

Améliorer sans tout briser

shutterstock_150960368

Dans le domaine du développement logiciel, nous sommes habitués au changement et nous avons l’habitude de nous doter d’un processus rigoureux d’amélioration continue, qui peut se simplifier par trois étapes : planification, action et évaluation. La planification nous permet d’avoir une vision assez précise sur une courte période temps. Au-delà de quelques semaines, on se contente d’une vision plus floue, mais toujours alignée sur l’atteinte de l’objectif. L’action est une phase intense de développement avec comme seul objectif la réalisation du plan de la phase précédente. Durant cette phase, il est souvent tentant d’accepter d’ajouter des choses qui n’étaient pas prévues ou d’en modifier. Toutefois, il faut s’en abstenir, et ce, pour deux raisons. Premièrement, le plan implique souvent toute une équipe. Le moindre changement de cap aura des conséquences sur les autres membres de l’équipe, ce qui pourrait compromettre le succès de leur travail. Deuxièmement, le plan est, par définition, une séquence d’événements qui n’arriveront pas exactement comme prévu; nous devons l’accepter. Le fait d’en rester au plan initial nous permet d’évaluer plus facilement les écarts lors de la troisième phase, soit l’évaluation. C’est en mesurant cet écart et en tentant d’en expliquer les raisons que nous pourrons tirer des conclusions qui, une fois transformées en points d’action, nous permettrons de nous améliorer. Cette méthode appliquée au développement d’un logiciel permet de transformer celui-ci par petits morceaux sans risquer de tout briser. Si une amélioration s’avère néfaste, elle peut être rapidement corrigée ou simplement, on peut la laisser tomber. La perte demeure négligeable à l’échelle du projet. C’est comme pour le lancement d’une fusée dans l’espace. Les ingénieurs savent planifier exactement la meilleure trajectoire pour atteindre leur objectif. Toutefois, lors de son ascension, il faudra constamment appliquer des corrections pour que la fusée ne dévie pas trop du plan initial. De fait, les vents, la pression atmosphérique et d’autres facteurs extérieurs peuvent influencer sa trajectoire. Dans le cas d’une fusée, cette trajectoire est évaluée plusieurs fois par seconde. Par conséquent, il est facile d’éviter les grandes déviations. Cependant, si par malheur une déviation s’avérait plus grande que ce qui était prévu, la mission serait immédiatement annulée, comme ce fut le cas pour la fusée Antares de la NASA le 30 octobre 2014. Avant d’annuler une mission, il faut d’abord en évaluer le coût; est-il plus cher de la maintenir ou de l’interrompre?

Préserver les données à tout prix

Il est parfois nécessaire, dans le cadre de changements majeurs à un logiciel, de changer la structure même des données qu’il utilise. Il faut absolument prévoir une stratégie pour conserver l’information utile tout au long des changements. Les stratégies pour y arriver sont variées. À une extrémité, on peut imaginer le développement d’une nouvelle solution en parallèle de l’existante et prévoir une migration totale des données à la fin du projet. Pour ce faire, il faut que le processus de migration soit entièrement automatisé et utilisé fréquemment pour tenir à jour les données du nouveau système. Le seul inconvénient de cette technique est que vous ne pourrez pas utiliser la nouvelle application avant qu’elle ne soit complètement terminée. À l’autre bout du spectre, il y a la possibilité de maintenir la structure telle quelle et de ne faire que des changements très circonscrits pour limiter l’impact sur l’application existante. Si jamais il fallait apporter une modification majeure, il faudrait alors décider soit de créer une nouvelle structure et prévoir la migration ou de changer l’application existante pour respecter la nouvelle structure. Selon les applications et la nature des changements, différentes nuances de ces techniques peuvent être utilisées. Par exemple, on peut opter pour une approche plus sécuritaire et éviter les changements de structure. Il sera toujours possible d’introduire de petits changements au cours du projet et même de basculer une partie du projet ou le projet en entier dans une nouvelle structure si jamais les changements requis nous y contraignaient.

S’assurer de ne pas perdre ses utilisateurs

Le meilleur logiciel au monde ne vaut rien s’il n’est pas utilisé. L’adoption de votre logiciel par vos utilisateurs est la clé du succès. Je dirais même qu’il faut aller jusqu’à susciter l’intérêt et consulter les utilisateurs pour les faire participer aux changements. Même si on passe beaucoup de temps à analyser le fonctionnement d’un logiciel pour en extraire le fonctionnement, il manque souvent une partie importante de la connaissance d’affaires. La plupart des logiciels ont des limitations, et les utilisateurs sont souvent très créatifs pour les contourner. Il faut leur poser des questions telles que celles-ci : Qu’est-ce que le logiciel ne fait pas pour vous? Que faites-vous manuellement? Quelles fonctions du logiciel trouvez-vous inutiles? Quels sont les problèmes avec le logiciel? Le but est de trouver les processus manuels cachés ou des voies de contournement que les utilisateurs ont appris à utiliser pour éviter les problèmes d’utilisation. Après tout, il ne faut pas oublier pour qui on développe le logiciel. Habituellement, ceux qui payent le logiciel ne sont pas ceux qui l’utilisent. Par exemple, si une entreprise se dote d’un logiciel pour gérer les feuilles de temps de ses employés, il sera utilisé par ceux-ci, mais payé par le patron. Dans ce cas, il est évident que ce patron aura des attentes envers le logiciel et, puisqu’il en assume le coût, naturellement, on sera tenté de l’écouter. Toutefois, si les employés ne sont pas satisfaits du logiciel, ils n’auront pas tendance à l’utiliser.

Faire du changement un succès

Tout changement est difficile. Et le volet le plus difficile du changement, c’est le volet humain. Puisque les gens ont des interactions avec les logiciels, il faut considérer l’impact des changements logiciels sur ceux-ci. Comment peut-on s’assurer que les changements se fassent en douceur? Comme je l’ai mentionné précédemment, il faut inclure les utilisateurs dans le processus de changement. Il faut les faire participer. Il faut qu’ils comprennent le bienfait des changements requis. Durant mes études secondaires, je me souviens d’un cours où nous devions simuler la commercialisation d’un produit. En fait, je me souviens de peu de choses. Cependant, j’ai retenu une chose importante : avant de faire le lancement d’un produit, il faut avoir déjà prévu son innovation. Je suis convaincu que le jour de la sortie du iPhone 5, Apple avait déjà le iPhone 6 sur la table à dessin. Il n’attentait que d’avoir un peu de feedback de ses utilisateurs pour y mettre la touche finale et en démarrer la production. En développement logiciel, c’est la même chose, et ce, même pour votre logiciel interne. Si vous êtes capable de livrer fréquemment de petites innovations pour votre logiciel, le niveau de confiance de vos utilisateurs augmentera. Toutefois, pour que cette confiance soit au rendez-vous, il faut que la qualité y soit aussi. Il est très difficile de livrer un logiciel ne comptant aucun problème. Les environnements de développement ne permettent pas de tester le logiciel dans son habitat naturel. Il faut être capable de le faire essayer pour « vrai ». Je vous présente ci-dessous deux techniques pouvant être utilisées pour atténuer les risques liés à l’impact d’un problème.

Fonctionnalités à interrupteur

Il est possible d’offrir une fonctionnalité actionnée par un interrupteur quelconque. Par exemple, si on parle d’un système de gestion de feuilles de temps, il est possible d’offrir l’importation des données à partir d’une feuille Excel. Cette fonctionnalité peut être actionnée par une configuration du logiciel. Ainsi, on peut facilement la retirer si on y découvre une faille majeure en cours d’utilisation, et ce, sans avoir à redéployer le logiciel en entier.

Sur invitation seulement

Parfois, il est trop complexe d’isoler une fonctionnalité à l’aide d’un interrupteur. Par exemple, lorsque la fonctionnalité fait partie intégrante du cœur du système et qu’elle interagit avec le reste du système. Dans ce cas, on peut faire un déploiement partiel ou sur invitation seulement. On peut également contrôler l’accès à la nouvelle version par des règles de sécurité. Dans tous les cas, ce que l’on veut, c’est donner accès à un groupe restreint d’utilisateurs afin qu’il nous donne du feedback sur l’utilisation du logiciel, et ce, sans pénaliser la masse. On peut même penser à une liste d’attente pour avoir accès à la nouvelle version. En plus de limiter les dégâts en cas de problème, on se sert du bouche-à-oreille pour favoriser l’adoption. Il y aura sûrement un utilisateur qui verra que son collègue a la nouvelle version, mais pas lui.

Conclusion

Il est possible de faire du neuf avec du vieux et de le faire en douceur. En découpant votre parc de logiciels en petits morceaux, il est possible de les migrer vers les nouvelles technologies sans perdre les données qui s’y trouvent. Je me souviens d’une époque où la mode était de tout refaire de zéro à chaque fois. Je pense qu’avec un peu d’intelligence et de créativité, on peut arriver à faire vivre un logiciel pendant plusieurs années. Il suffit d’y croire et d’y mettre les efforts nécessaires.

Découvrez comment Pyxis /studio peut développer votre logiciel sur mesure. Nous nous spécialisons en développement sur mesure pour des clients qui cherchent des solutions uniques et qui veulent maximiser la valeur de leur investissement. Depuis plus de 13 ans, notre équipe de développement a fait la preuve de son Agilité, de sa créativité, de son esprit collaboratif et de son engagement indéfectible envers nos clients.

Billet précédent

Le Graal de l’Agilité?

Billet suivant

Combien coûte le développement de son logiciel personnalisé?

éric de carufel

Passionné, impliqué et minutieux sont des qualités qui décrivent bien Éric pour qui le développement logiciel est une quête constante d'amélioration pour atteindre un équilibre entre la perfection et les besoins du client. Son approche architecturale est simple : élaborer une architecture où il est plus facile d'appliquer les bonnes pratiques que les mauvaises.

Son implication en tant que conférencier et blogueur est reconnue par Microsoft, qui lui a décerné le prix de "Most Valuable Professional in Visual C#" (MVP C#) chaque année entre 2009 et 2015.