« C’est l’algorithme qui l’a dit » ou la déconnexion du logiciel et du métier

badcomputerday

Les premiers retours d’APB, logiciel gérant les souhaits des élèves pour leurs études après le Bac, ont été publiés récemment, avec leur lot de retours négatifs et d’incompréhensions de la part d’étudiants et de parents mécontents du résultat final. Pour expliciter ce phénomène les commentateurs utilisent la formule « c’est un algorithme qui décide », comme si le destin de nos enfants dépendait du bon vouloir de froids circuits imprimés. J’ai même entendu sur une radio une mère indignée menacer sur un ton mi-humoristique « si je trouve l’ordinateur qui a fait cela, que je lui explique ma façon de penser ».

Cette réaction est assez classique quand la décision est prise par un système informatique : celle-ci prend un aspect arbitraire et injuste, parfois plus que quand elle est prise par un être humain. Cette vision est paradoxale car dans la plupart des cas (écartons les algorithmes neuronaux, mon directeur technique en parlera) l’ordinateur applique de façon impartiale et linéaire les règles qui lui ont été indiquées par ses concepteurs. Donc si une question doit être remontée, ce n’est pas au produit mais aux concepteurs des règles fonctionnelles qui le composent. Or après une longue période d’utilisation le logiciel est personnifié par son utilisateur, et se sépare de ses concepteurs.

Revenons au métier, et en particulier à une phase importante de la vie d’un logiciel métier : le moment où la grande majorité (voire la totalité) des utilisateurs d’une application ne connait plus les règles qui expliquent la réaction d’un logiciel.

Il m’est arrivé plusieurs fois, dans le cadre de projets qui durent plusieurs années, d’avoir à expliquer à mon client, qui connait son métier, pourquoi le logiciel, qui applique son métier, prenait telle ou telle décision. Aussi surréaliste qu’elle puisse paraître cette inversion des rôles est finalement assez compréhensible. Je vais dans la suite de cet article l’expliquer, et donner des clés ergonomiques et organisationnelles pour l’éviter.

La perte de contrôle

Pour comprendre cette perte de contrôle, revenons au principe d’une application métier : l’un de ses objectifs est de faire gagner du temps à utilisateur en appliquant plus efficacement les règles de son métier qui sont suffisamment systématiques et simples pour d’une part être applicables sans erreur, et d’autre part que le fait que ce soit un être humain qui l’applique n’apporte aucune valeur ajoutée. Par exemple, dans une application de validation de dossier de normes, il n’y a aucun intérêt à demander à un utilisateur de vérifier dans un dossier la présence d’un document, un ordinateur le fera plus rapidement. De la même manière, historiquement la première application qui a provoqué l’engouement pour les ordinateurs personnels (même maintenant d’ailleurs) est le tableur : pourquoi faire les calculs compliqués et inintéressants si un ordinateur peut les exécuter instantanément pour nous?

Lorsqu’un utilisateur appuie sur un bouton de son application des milliers d’actions et de calculs peuvent se déclencher en quelques millisecondes pour afficher à l’écran un oui ou non. L’utilisateur n’a aucun intérêt à refaire le calcul lui même, le résultat est fiable, et on a gagné des heures et des heures. Mais la conséquence de cela est que l’utilisateur, même s’il est au fait de par sa connaissance du métier des règles qui sont en jeu, finit par perdre de vue la série d’opérations qui est effectuée, et l’action devient quasiment magique (le terme de « bouton magique » a souvent été évoquée par nos utilisateurs pour décrire un composant de leur application).

Les cas typiques où cette incompréhension est particulièrement forte sont les cas particuliers d’utilisation de l’application. En effet dans un cas non usuel, l’utilisateur attend une réponse de la part du logiciel conforme à sa vision des règles appliquées et non conforme aux règles telles qu’elles sont inscrites. Du coup la réponse du logiciel paraît peu cohérente voire complètement fausse.

Comment l’éviter

Commençons par le plus important : le mode d’emploi de l’interface utilisateur n’est pas la solution pour éviter ce type de problème. Si je reprends l’exemple d’APB, tous les utilisateurs qui ne comprennent pas la décision finale ont comme argument : « mais je l’ai bien rempli pourtant », et c’est vrai. Le problème ici ne réside pas dans une mauvaise utilisation du logiciel mais dans une mauvaise compréhension du résultat de la bonne utilisation.

Les pistes pour éviter ce type de problème sont les suivantes :
 – Entretenir la confiance dans le logiciel : la première solution pour éviter les incompréhensions est que l’utilisateur ait un a priori positif sur la qualité de la réponse du logiciel. C’est pour cette raison que les premiers mois d’utilisation d’une application métier sont décisifs : ils construisent sa réputation. Si celle ci est mauvaise, et même si au final le logiciel fonctionne, les retours négatifs vont se multiplier car les utilisateurs vont croire que le retour étrange est tout simplement un bug.
Expliciter les décisions : quand un logiciel propose une résultat qui nécessite plusieurs étapes de calcul, il n’est pas déraisonnable de les expliciter en quelques phrases. Dans 90% des cas, l’utilisateur ne va pas lire ce petit résumé, mais celui-ci sera primordial dans les 10% restants. Un bon exemple dans le grand public est l’application web de saisie de la feuille d’imposition, qui propose en quelques lignes une explication du montant de l’impôt sur le revenu final.
Rendre l’interface de saisie la plus proche possible du processus de décision de l’ordinateur : par exemple, si les conditions de décision dépendent de l’état du dossier dans un cycle, il est préférable que soit présents à l’écran l’état de l’objet, le cycle et la position de l’objet dans le cycle. Le but est de donner à l’utilisateur la possibilité d’apprécier la situation en un coup d’oeil et d’éviter les qui pro quo.
Décrire dans une documentation les workflow de façon synthétique, et valider que cette documentation est précisément ce qui est appliqué dans le logiciel, et surtout la mettre à jour au fur et à mesure. Il m’est arrivé plusieurs fois d’avoir des rapports d’erreur concernant des calculs, et l’utilisateur qui écrivait le rapport d’erreur utilisait comme référence un tableur excel qu’il avait fabriqué pour l’occasion, mais sans l’avoir maintenu : un beau dialogue de sourds !
Créer un forum utilisateur : l’avantage de cette solution est qu’elle présente des cas pratiques. Mais c’est une arme à double tranchant : il est impératif que le forum soit modéré et validé par quelqu’un qui maîtrise les processus décrits dans l’étape ci-dessus. Toute personne ayant consulté des forums sur internet sait que l’on peut trouver des mauvaises idées tout comme des bonnes.

La leçon à retenir de ce type de problème est que l’évolution d’une application pendant sa vie n’est pas uniquement interne : l’évolution de son environnement et de ses utilisateurs fait partie intégrante de son cycle de vie et doit être prise en compte dès le départ dans sa conception. Cette phase est souvent oubliée, et cet oubli se paye des mois voire des années après l’écriture de la première ligne de code. Encore une bonne raison de placer l’utilisateur au centre du système d’information!

Les méthodes agiles : agile oui mais surtout méthode!

cadavre

Le cadavre exquis, application dans l’Art de la méthode agile

Scrum, XP, DSDM, FDD… derrière ces acronymes se cache un concept de méthode de conception et de fabrication de produits informatique : la méthode agile. Le principe de base est simple : le produit informatique est immatériel, donc le coût de mise sur le marché (en production) d’une nouvelle version est négligeable par rapport à celui de n’importe quel autre secteur de l’industrie. Donc pourquoi ne pas proposer des mises en production en cours de réalisation, pour pouvoir affiner le produit directement au contact de l’utilisateur ?

En ce qui concerne la définition de la méthode, je vous propose de lire la fiche Wikipedia de description de la méthode agile, et en particulier les principes fondamentaux que je ne vais pas énoncer dans l’article. Je rappelle juste que le principe de la méthode agile est de créer le produit par itérations, chaque itération donnant lieu à une mise en production auprès des utilisateurs et à une mise à jour des spécifications de l’itération suivante, le tout suivi par des réunions et comités réguliers.

L’idée est extrêmement séduisante : l’utilisateur est alors mis au centre du processus de conception, et y participe activement pour un résultat qui ne peut que le satisfaire. Cela s’applique particulièrement au métier de la conception d’applications personnalisées, où le constat à éviter absolument lors de la mise en production de l’application est que l’orientation du produit ne soit pas en adéquation avec les besoins des utilisateurs. Vous pensez donc : « est-ce donc le design pattern idéal de Marc Lemaire et de Yoocan ? ».

Ma réponse est plus nuancée, et je vais la développer en évoquant en premier lieu le principe de la méthode, ses avantages et ses inconvénients, puis son implémentation (car non tout ne se passe pas comme dans le manuel!).

1) Avantages et inconvénients en théorie

Sur le principe inclure les utilisateurs en livrant de façon itérative est une bonne solution dans les cas suivants :

  • Le métier est particulièrement complexe et difficile à aborder : une démarche itérative évite les erreurs de conception dues à une mauvaise compréhension
  • Le volume d’utilisateurs est très faible : la coordination est très simple
  • L’ergonomie ou les fonctionnalités sont très innovantes : le retour des utilisateurs est essentiel sur un fonctionnement complètement nouveau
  • Le métier de l’utilisateur est innovant pour la même raison

D’un autre côté, également sur le principe il vaut mieux éviter ce type de méthode dans les cas suivants :

  • Le projet est une V1 avec un budget ou un temps limité : la méthode itérative demande du temps et en particulier du temps de réunion, donc c’est peu adapté pour un produit dont la phase de développement doit être la plus rapide possible.
  • Le projet est l’implémentation directe de la stratégie de l’entreprise : l’itération peut faire perdre de vue l’objectif principal du projet, et l’objectif d’évolution stratégique disparaît au fur et à mesure des itérations.
  • Il n’y a pas de rôles clairement définis chez le client (notamment pas de rôle de décision) : la démarche itérative demande la coordination des acteurs, chacun ayant un rôle bien précis. La non définition de ces rôles rend la communication et la prise de décision très complexe.
  • Un projet avec une part importante de recherche : la recherche et développement doit être confiée à la direction technique en premier lieu. La démarche de recherche est agile par définition, mais pas agile dans le sens des méthodes agiles.

2) Dans la pratique : les écueils à éviter

Dans la pratique, la réussite de l’application d’une démarche agile demande le bon suivi de chacun de ses règles.

Or l’application de cette méthode s’accompagne parfois de l’oubli conscient ou non de ces règles, et donne lieu aux comportements suivants

  • Itération sans livraison : il faut dans une démarche agile que l’application soit mise au contact des utilisateurs (règle 3). Ne pas passer par cette étape et itérer sans contact en vie réelle augmente considérablement le risque de hors-sujet, plus parfois que pour un cycle en V classique.
  • Itération sans rédaction de documentation ou validation technique (règles 9 et 11) : l’application évolue et donc son plan doit évoluer en restant lisible si on prend le projet de A à Z. Si vous créez un cagibi et ajoutez les pièces pour obtenir une maison au fur et à mesure, il paraît être du bon sens de maintenir un plan complet. Ce bon sens a tendance à être oublié au quotidien dans la conception d’un produit informatique.
  • Itération sans recette complète (règles 4, 7 et 12) : ces règles utilisent le terme d’applications fonctionnelles. Cela signifie que l’application doit être complètementfonctionnelle, et donc le métier et la technique doivent collaborer pour valider (même si l’évolution ne porte que sur une part du métier) un cahier de test reprenant les processus dans leur globalité.

Pour moi le problème de la non compréhension de l’intérêt de la méthode agile réside dans son nom. Le nom d’agile convient pour exprimer la qualité de cette méthode pour stimuler la créativité technique et fonctionnelle, et obtenir des produits innovants et proches du besoin final. Mais il y a une tendance à confondre agilité et manque de rigueur.

Durant ma carrière j’ai rencontré de nombreux chefs de projets ou dirigeants qui pensent qu’implémenter une méthode agile permet de ne suivre aucun plan de développement et de ne travailler qu’au fil de l’eau, sans cadre. Or au contraire l’application d’une méthode agile demande un surcroit de rigueur dans le suivi technique et fonctionnel, et ce afin d’éviter d’aboutir à une usine à gaz impossible à maintenir.

En conclusion, si vous voulez obtenir un beau cadavre exquis, il faut que tous les dessinateurs connaissent leur métier, leur rôle et leur style. Sinon vous obtiendrez un infâme gribouillis inexploitable.

Réussir un projet – Episode 2 : l’avant vente

SouffléConséquence d’une phase d’avant-vente trop rapide

Je vais être franc, je suis un peu gêné pour écrire cet épisode, car pour moi pour réussir une avant-vente la solution c’est choisir Yoocan. Cependant en tant que chef de projet et consultant j’ai suivi de nombreuses phases d’avant-vente, et j’ai l’intention ici d’énoncer les problématiques importantes ou les éléments que j’attends d’un client en prospection.

Cet article tient pour acquis le fait que vous avez lu et que vous avez suivi les conseils de mon épisode 1 et que donc votre besoin est bien défini et votre opinion affirmée.

La spécificité de la vente d’un logiciel informatique consiste en l’immatérialité du produit fini, ce que signifie que vous êtes dans un centre commercial face à des rayons pleins de produits invisibles, rendant très compliquée la tâche de choisir le bon parmi tous ceux qui existent. Quelques conseils pour décrypter les offres.

Je vais supposer également que vous êtes un fan de mon blog et que vous avez lu mon article sur le cloud, qui vous aidera à comprendre quoi choisir parmi les différents types d’accès à votre logiciel.

Donc vers quel type de solution se diriger : logiciel tout fait ou solution personnalisée? Il ne vous est pas du tout interdit de prospecter pour les deux, mais il serait intéressant que d’avoir dans votre for intérieur une opinion sur la question.
Cette question est équivalente à la suivante : est-ce que je veux le même logiciel que mon voisin ? La réponse peut être oui : vous voulez un système de partage de fichier avec versioning, un logiciel de compta, ou un CRM orienté annuaire client sans fonctionnalité spécifique à votre métier, faire développer cela de A à Z revient à peu près à réinventer la roue. Pour ma part j’ai parfois répondu à des appels d’offre en répondant « prenez tel ou tel logiciel, pas la peine de passer par nous pour faire ce que vous voulez ».
Par contre si vous voulez que votre valeur ajoutée spécifique soit concentrée dans votre application, attentions aux sirènes du « prenez un logiciel (à licence ou gratuit), nous le personnaliserons », car d’une part les personnalisations peuvent être très chères et d’autre part il vaut mieux parfois partir de rien plutôt que d’une base peu adaptée.

En dehors des fonctionnalités proposées, de la technologie utilisée, des raisons de politique interne ou de la faconde du commercial en face de vous, pour une application métier les notions suivantes sont très importantes à vérifier : bien sûr le prix, mais également le périmètre d’utilisation, et la pérennité, et le mode de réponse de vos candidats.

Que cache un prix? Le prix d’une application est principalement en quatre parties : le coût de licence, le coût de paramétrage / développement / formation, le coût d’hébergement, le coût du contrat de maintenance. Dans beaucoup de proposition ces coûts sont confondus : une licence annuelle d’utilisation d’un produit contient souvent la maintenance, le coût d’une application en SaaS sur le cloud confond l’hébergement et la maintenance. Dans tous ces coûts un seul n’est pas récurrent. Il peut être paradoxal de voir des sociétés gagner de l’argent sur la base de logiciels libres, mais ce qui est gratuit est uniquement la phase 1 du coût, et pas le reste. Je suggère soit de demander au commercial soit d’établir vous même un planning de facturation sur 3 ans. Faites attention également aux coûts de licence par utilisateur : très avantageux au début, ce type de facturation peut être incohérent avec une stratégie de croissance où l’augmentation du budget d’un département ne doit pas être linéaire.

Il ne faut pas également oublier dans le coût d’une application la possibilité d’en faire financer une partie. Le plus simple : la partie formation peut être intégrée à votre budget formation si la société est ou possède un organisme agréé. Un autre : le CIR (Crédit d’Impôt Recherche pour la recherche et développement) et surtout le CII (Crédit d’Impôt Innovation, pour la conception d’un prototype de produit innovant), permettent de faire financer en économie d’impôt le développement de votre solution.

Une autre information qu’il est essentiel d’évoquer lors d’une réunion commerciale est : quel est le périmètre d’utilisation de l’application, et quelles sont ses limites notamment en terme de charge ? J’ai construit plusieurs applications qui étaient destinées à 10-15 utilisateurs permanent, et qu’il a fallu reprendre quand ce chiffre est passé à plusieurs centaine d’utilisateurs. Le client s’est attendu au surcoût car je l’avais prévenu au départ. Il est donc essentiel pour vous de savoir dans quelle mesure le logiciel peut être utilisé : combien d’utilisateur en même temps, combien d’utilisateurs au total, volume de données maximum, les heures d’exploitation (si par exemple des mises à jour doivent être effectuées à heures régulières).

Pour terminer une application métier est une application que vous allez utiliser au quotidien avec à mon opinion une durée minimum d’exploitation de 3 ans. Il est donc nécessaire pour vous client de suivre comment l’application peut évoluer.
Concernant un logiciel, il est nécessaire de vérifier la santé de l’éditeur, la durée d’exploitation du logiciel et s’il existe un autre intégrateur (un de mes anciens clients a du recréer toute une solution en 3 mois car le seul intégrateur restant du logiciel est parti devenir professeur de plongée en Thaïlande).
Concernant une application personnalisée, la santé de l’entreprise doit également être surveillée, la technologie connue d’au moins un autre intégrateur (et attention à la notion de framework, j’écrirai un article sur le sujet dans les prochains jours), et la proposition commerciale doit contenir une partie de documentation technique pour permettre une reprise par une autre équipe, et surtout une description fonctionnelle et technique basique du mode de fonctionnement de la solution proposée : dans le cadre d’une application personnalisée, il vous faut vérifier que votre futur prestataire a bien compris votre besoin.

En conclusion, quelle que soit l’option prise, une application métier est une solution qui définira votre façon de travailler pendant quelques années, donc le choix du prestataire doit être fondé non seulement sur la qualité technique et fonctionnelle, mais également sur la capacité de votre prestataire à vous accompagner dans la durée.

 

Réussir un projet – Episode 1 : décider de lancer le projet

 280px-Leaning_tower_of_pisa_2Avant de faire les plans, il fallait vérifier le terrain…

Lors d’une discussion avec un ami à propos de l’aviation civile, activité dangereuse s’il en est, celui ci m’a donné un conseil plein de bon sens : « le secret de la survie en avion, c’est de savoir quand ne pas décoller ».

On pourrait croire que je ne prêche pas pour ma paroisse en écrivant cet article sur la prise de décision, avec comme objectif d’indiquer quand renoncer, mais je préfère les projets qui réussissent, et à l’instar de cette illustration, il existe des projets mourants avant même leur conception. Ce temps de réflexion ne sera pas perdu, il ne s’agit pas de temps supplémentaire, mais d’anticiper une phase qui a lieu quoi qu’il arrive.

Volontairement ici je ne me poserai pas la question du budget, celle-ci sera évoquée lors de mon article sur l’avant-vente. De la même façon je ne parlerai pas ici d’une application grand public, mais bien d’une application métier.
Voici donc les questions à se poser avant de décider de refondre une application, de concevoir une nouvelle application pour un métier existant, ou même d’acheter un nouveau logiciel sur l’étagère.

Commençons par la question évidente : pourquoi ce projet? La réponse à cette question peut être technique (utiliser des outils plus modernes, abandonner une technologie passée de mode ou non maintenue),  mais pour moi si cette raison est la seule, elle ne sera pas comprise par l’utilisateur final. Le pire scénario est pour moi : « prenons cette belle techno toute neuve et faisons de l’isofonctionnalité » : une application doit apporter quelque chose de nouveau.
D’un point de vue fonctionnel, la réponse peut venir d’une volonté stratégique ou d’une demande utilisateur. Il est préférable de mélanger les deux : si le patron veut une application pour créer un nouveau métier, il doit tâter le terrain avant investissement auprès des utilisateurs, et si c’est une demande utilisateur, elle doit être validée par un responsable qui comprend l’utilité de la fonctionnalité demandée.

La deuxième question coule de source : est-ce que mon besoin est suffisamment défini? Un nombre incalculable de prospects (ou clients), répondent à la question « que voulez vous? » par « je veux un CRM » ou « je veux un ERP » ou (mot à la mode) « je veux un algorithme » ou encore « je veux un ERP avec une IHM qui n’est pas une UAG » (le premier qui me donne la signification de tous les acronymes de cet article dans les commentaires gagne 15 minutes de consulting gratuit).
Ceci ne veut rien dire, je peux citer une douzaine de projets de CRM radicalement différents d’un point de vue philosophie de conception et qui sont tous des CRM. Il faut donc avoir une idée précise des fonctionnalités principales, et surtout préparer un discours et un cahier des charges (même peu détaillé) clair et compréhensible à transmettre en avant vente : qui utilise l’application, pourquoi, qu’est ce qui sera stocké, quelle sera la volumétrie de données approximativement. La précision diminue la perte de temps d’explication en avant-vente et vous permet d’être réactif voir proactif dans la suite du projet.

Après le pourquoi, le quoi, voici le quand : quand le projet doit il être fini? J’ajoute même une question subsidiaire : si cette date de finition n’est pas atteignable, quelle serait la date de prochaine finition?
La deadline contribue à la réussite du projet, même si elle est peu réaliste. Par contre il vaut mieux en déterminer au départ au moins deux, même si l’existence de la deuxième date est tenue secrète, cela permet d’une part d’être réceptif à une livraison par lot, d’autre part de pouvoir se retourner rapidement et efficacement en cas de problème en présentant un retro planning cohérent avec l’exploitation.

Parlons maintenant des questions pratiques lors de la conception, de la recette et de l’utilisation finale. La première question est : est-ce que mes équipes peuvent suivre un nouveau projet ? Nous évaluerons lors de la phase d’avant-vente les besoins en fonction de la solution abordée en ressources internes, mais aucun logiciel (même la suite office) ne s’installe dans un entreprise sans un travail de ses collaborateurs : réflexion, choix avant-vente, réunion de suivi des développements, recette, et utilisation attentive avec remontées de bug en production. Beaucoup de projet perdent un temps précieux car les collaborateurs même de bonne volonté n’arrivent tout simplement pas à trouver du temps. Cette question est à rapprocher du « quand », car évidemment la réponse dépend du plan de charge du service et donc de la période de l’année.

Autre question : est-ce qu’il n’existe pas des contraintes pratiques empêchant l’utilisation de l’application? Ces contraintes peuvent être très diverses : doublon avec une application déjà utilisée, données trop complexes ou trop contraignantes à saisir, utilisateur incapables techniquement d’utiliser l’application, trop de cas particuliers trop important pour justifier une utilisation d’une solution automatique, etc…
Une personne talentueuse  mais peu technique nous a demandé un outil de conception automatique d’interface graphique en JAVA. L’outil fonctionnait bien et était conforme à la demande, mais l’utilisateur a constaté qu’il n’avait tout simplement pas les compétences techniques et les automatismes intellectuels pour l’utiliser à bon escient.
Une autre société nous a demandé un outil pour que leur utilisateurs (des monteurs vidéos) saisissent toutes les informations matérielles d’une opération : outils utilisés, temps passés, usure des pièces, salles occupées. Au final les utilisateurs finaux n’ont jamais pu concilier l’urgence du terrain avec la saisie de ces informations.
Enfin une société nous a demandé de créer une application pour gérer la commande de vêtements. Le responsable avait monté un modèle de processus et de devis pour automatiser une grande partie du travail, mais le modèle s’est avéré ne correspondre qu’à une toute petite partie des commandes possibles, et l’application en est devenu inutilisable.
Ces trois projets ont un point commun : ils n’auraient jamais dû dépasser la phase de la réflexion.

Dernière question pratique souvent oubliée mais essentielle : dans le cas d’une refonte, que faire des données existantes? L’exploitation d’une application peuvent permettre d’enregistrer l’équivalent de millier d’heures de saisie, et s’il n’existe pas de processus automatique ou qu’aucune décision stratégique n’a été prise en en ce qui concerne la transition, au moment d’une refonte l’obstacle peut s’avérer infranchissable. Une non reprise des données est vraiment un classique du ratage d’application, il est donc nécessaire d’aborder ce sujet très sérieusement.
Un de nos clients nous a demandé une application de gestion de personnes et de groupes de travail, avec des options de recherche et de catégorisations très intelligentes. L’application a été conçue et réussie, mais le seul problème était que le client n’a jamais pu mettre dans une forme exploitable les dizaines de milliers de personnes et les centaines de groupes créé dans la dernière version de l’application.
Les solutions peuvent être complexes (remise en forme des données, saisie semi automatiques), optimistes (le prestataire saura bien se débrouiller) ou drastiques (table rase), mais il est nécessaire de retenir dès maintenant un point qui reviendra en phase de recette et d’exploitation : la ligne entre l’ancienne et la nouvelle application doit être ferme et marquée (suppression pure et simple de l’application précédente, date butoir, périmètres fonctionnels ou géographiques bien défini). Toute utilisation floue de deux applications en même temps résulte en erreurs, double saisie et données perdues.

Conclusion : rien ne sert de courir, le temps de la réflexion peut avoir lieu avant de décrocher le téléphone pour appeler son prestataire favori, et en plus permettra d’avoir d’ores et déjà la réponse à des questions que tout bon architecte métier vous posera.