Faire évoluer son outil métier au fil du temps

Un outil métier livré et recetté correspond à ce que votre entreprise faisait le jour de la recette. La norme internationale consacrée à la maintenance dans le cycle de vie d’un logiciel, ISO/IEC/IEEE 14764, compte cinq raisons de le modifier après cette date : corriger un défaut, prévenir un défaut latent, l’adapter à un environnement qui a changé, améliorer ce qui existe, et ajouter ce qui n’existe pas. Deux seulement de ces cinq raisons se choisissent, et elles viennent du même endroit, votre entreprise. Les trois autres arrivent d’elles-mêmes, avec ou sans votre accord. Faire évoluer son outil métier au fil du temps revient donc à décider une part réduite de ce qui sera modifié, et à ne pas laisser cette part se décider seule, au rythme où les demandes arrivent. Cet article dit lesquelles des cinq raisons vous appartiennent, comment trier les demandes d’évolution avant de les chiffrer, pourquoi livrer par versions datées plutôt qu’à la demande, quelles cinq questions poser à votre outil une fois par an, et qui tient cette trajectoire quand personne n’est payé pour y penser.

Cinq raisons de modifier un outil qui fonctionne, dont deux seulement vous appartiennent

La norme sépare les modifications d’un logiciel en service selon ce que chacune vise, et elle se donne pour champ la maintenance d’un logiciel tenue en interne comme confiée à un prestataire, ce qui couvre un outil de gestion développé pour votre entreprise. La correction répare un problème découvert après la livraison. Elle ne se décide pas : un calcul de marge faux se corrige, et la seule question porte sur le délai. La prévention corrige un défaut qui ne s’est pas encore produit, une bibliothèque connue pour une faille, un traitement qui tiendra jusqu’à un certain volume et pas au-delà. Elle ne se voit pas à l’écran, donc aucune demande ne la porte, et c’est le poste qui s’accumule quand l’outil n’a plus de suivi. Ce retard accumulé est la dette technique, et ce que ce rattrapage coûte, et sur quelle ligne il se finance, a sa propre page.

Restent trois raisons, qui se ressemblent dans les demandes reçues et n’ont pourtant rien en commun quant à la décision. L’adaptation suit un changement survenu en dehors de votre entreprise. L’amélioration et l’ajout suivent un changement survenu dedans. Le prestataire qui reçoit une demande d’évolution ne fait pas la différence à sa lecture : la demande décrit un formulaire à modifier, sans dire d’où vient le changement. La différence apparaît dans la question de savoir qui a fixé la date.

L’adaptation à ce qui change dehors, où vous ne choisissez que le moment de la lancer

La maintenance adaptative garde l’outil utilisable dans un environnement qui a changé. Cet environnement comprend la réglementation, les logiciels avec lesquels votre outil échange des données, et le socle technique sur lequel il repose. Dans les trois cas, quelqu’un d’autre décide de la date, et il ne la déplace pas pour vous. Le guide pratique de démarrage de la facturation électronique, publié par la Direction générale des Finances publiques en juillet 2026, le dit en toutes lettres pour les entreprises déjà soumises à l’obligation d’émission : cette obligation n’est pas suspendue par les difficultés de démarrage que peuvent rencontrer l’entreprise, son prestataire ou son système d’information. Le même guide annonce qu’aucune sanction ne s’appliquera pendant la phase de démarrage aux entreprises engagées dans une trajectoire sérieuse de mise en conformité, et précise que cette approche ne constitue ni un report ni une suspension de l’obligation. À propos d’une facture reçue que le logiciel ne sait pas encore traiter, il range parmi les difficultés que l’entreprise doit identifier une difficulté avec le logiciel comptable ou l’outil de gestion. Un outil métier qui produit des factures, ou qui alimente le logiciel qui les produit, se vérifie donc avant une date qui ne dépend ni de son état, ni de votre budget, ni de la disponibilité de votre prestataire, et ce qui manque se modifie avant elle.

La même logique vaut pour les composants techniques sur lesquels l’outil repose : leur obsolescence a une date, et c’est leur éditeur qui la fixe. Une adaptation reportée ne disparaît pas, elle change de taille. Quand elle a été reportée assez longtemps pour que plus aucune version suivie ne soit atteignable directement, elle rejoint les chantiers qui s’ouvrent quand le socle lui-même arrive en fin de vie, et le travail change de nature, d’une évolution à une reprise. Sur l’adaptation, vous ne décidez que de la date de lancement, entre aujourd’hui et l’échéance.

Les améliorations et les ajouts, les deux raisons qui se décident chez vous

La norme, dans son édition de 2022, distingue l’amélioration de ce qui existe, qu’elle nomme perfective, et l’ajout de fonctions nouvelles, qu’elle nomme additive. Pour votre entreprise, les deux viennent du même endroit : un service qui travaille autrement qu’à la recette, un responsable qui veut voir un chiffre que l’outil ne sort pas, une équipe qui a grandi et dont les nouveaux arrivants ne comprennent pas un écran conçu pour une équipe dont les membres se parlaient. Les prestataires rangent ces deux raisons sous le nom de maintenance évolutive. C’est le poste où la demande, le calendrier et le budget sont entre vos mains, et c’est pour cette raison qu’il peut dériver : aucune date extérieure ne vient le borner.

Cette dérive prend deux formes opposées, et aucune des deux ne se voit dans le mois où elle commence. La première est l’outil figé : les demandes existent, personne ne les porte, et les équipes s’organisent autour de ce qui manque. La seconde est l’outil qui grossit : chaque demande est livrée dans l’ordre d’arrivée, l’outil compte plus d’écrans qu’à la recette, et le temps de chaque modification suivante s’allonge parce que chaque écran ajouté est un écran à ne pas casser. Les deux sections qui suivent portent sur ce poste.

Trier les demandes d’évolution avant de les chiffrer

Une demande d’évolution fonctionnelle, c’est-à-dire une modification de ce que l’outil fait et non de ce sur quoi il tourne, arrive formulée comme une solution : ajouter une colonne, rendre un champ obligatoire, envoyer un mail automatique quand un dossier change d’état. Chiffrer cette solution telle qu’elle est formulée revient à confier la conception de l’outil à la personne qui a eu le temps d’écrire un mail. Trois questions se posent avant tout chiffrage, et la réponse à deux d’entre elles ne dépend que de vous.

La demande décrit une solution, le besoin décrit une gêne

La première question consiste à retrouver la gêne derrière la solution proposée. Une demande de colonne supplémentaire dans un tableau cache une information que quelqu’un va chercher ailleurs, et la réponse peut être la colonne, ou un tri, ou un export qui existe déjà et que le demandeur ne connaît pas. Une demande de champ obligatoire cache une information manquante au moment où quelqu’un d’autre en a besoin, et la réponse peut être l’obligation, ou un rappel, ou une valeur par défaut. Trois réponses du demandeur suffisent à la retrouver : ce qu’il fait aujourd’hui à la place, combien de fois par semaine, et ce qui se passe quand ce n’est pas fait. La troisième pèse plus que les deux autres. Une gêne sans conséquence est un confort, et un confort attend la version où il ne coûte presque rien parce qu’un développeur est déjà dans cet écran.

Ce travail de reformulation revient à quelqu’un qui connaît le métier de l’intérieur. Un développeur qui reçoit « ajouter une colonne » ajoute une colonne, et il a raison de le faire. La gêne d’origine n’est visible que de l’intérieur de votre entreprise, et c’est la personne qui tient les demandes chez vous, votre référent, qui la retrouve, en allant voir le demandeur à son poste plutôt qu’en répondant à son mail.

Le coût se lit dans ce que l’évolution touche, pas dans sa taille à l’écran

La deuxième question porte sur ce que la modification touche, et la réponse ne se devine pas depuis l’écran. Un nouvel écran de consultation, même large, touche peu de choses : il lit des données qui existent et ne modifie aucun calcul. À l’inverse, changer une règle de gestion, c’est-à-dire une règle que l’outil applique partout où la donnée circule, comme le mode de calcul d’une remise ou la définition d’un dossier « en retard », touche chaque écran, chaque export et chaque total qui s’en servent. La demande tient en une ligne et la modification traverse tout l’outil. C’est le cas où une évolution simple en apparence se chiffre en jours, et où le devis surprend.

Cette question en appelle une autre, sur les données déjà enregistrées. Rendre un champ obligatoire pour les nouveaux dossiers oblige à décider ce que deviennent les dossiers existants qui ne l’ont pas rempli : les laisser vides, les compléter à la main, les remplir par une règle. Cette migration de données n’apparaît dans aucune demande, et le chiffrage doit la compter. Avant de chiffrer, demandez donc à votre prestataire deux choses, quels écrans et quels calculs cette modification traverse, et ce qu’elle impose aux données déjà présentes. Une réponse à ces deux questions vaut plus qu’un montant, parce qu’elle vous dit si la demande est ce qu’elle a l’air d’être.

Refuser, et garder la trace du refus

La troisième question revient à dire non à un collègue. Deux critères tranchent sans ménager personne. Qui d’autre, dans l’entreprise, a le même besoin : une demande portée par une seule personne décrit la façon de travailler de cette personne, et l’entreprise n’a pas à la financer tant qu’une deuxième ne la rejoint pas. Et qu’est-ce qui s’arrête si la modification n’est pas faite : une facture qui part en retard, un client sans réponse, une donnée obligatoire qui manque à un contrôle. Une demande à laquelle rien ne s’arrête attend la version suivante, et elle y revient si une conséquence est apparue entre-temps.

Le refus s’écrit, avec sa date et son motif, dans la même liste que les demandes retenues. Cette liste des demandes refusées vaut autant que l’autre. Une demande refusée qui revient dans l’année, portée cette fois par d’autres personnes, a changé de nature entre-temps, et la liste est le seul endroit où ce changement se voit. Sans elle, chaque retour repart de zéro, avec le même débat.

Livrer par versions datées plutôt qu’à la demande

Chaque livraison a un coût fixe qui ne dépend pas de la taille de ce qu’elle contient. Il faut tester la modification dans un environnement de recette, la faire valider par quelqu’un de votre côté, la mettre en production à un moment où les équipes ne travaillent pas dessus, prévenir les utilisateurs, et mettre à jour les procédures internes qui décrivent l’écran modifié. Livrer une demande à la fois, au moment où elle est validée, paie ce coût fixe à chaque demande, et les utilisateurs reçoivent un outil qui change à chaque validation.

Une version livrée a un périmètre fermé : elle regroupe les demandes retenues sur une période, les recette ensemble, les met en production le même jour et les annonce aux équipes d’un seul message. Le rythme se décide, et il se tient : un trimestre, un semestre, une date liée à votre activité, hors de la clôture ou de la haute saison. Ce rythme change deux choses. Il donne aux demandeurs une date de réponse au lieu d’une file d’attente, et votre référent fait le tri décrit plus haut sur un lot entier, où les demandes se comparent entre elles, au lieu de les trancher une à une alors que, prises isolément, elles se justifient toutes. Une version peut être vide : un trimestre sans demande qui passe les trois questions dit que l’outil couvre le travail tel qu’il se fait aujourd’hui. Les corrections urgentes, elles, sortent de ce rythme et se livrent quand elles sont prêtes, ce qui est une raison de plus de les séparer des évolutions dès leur arrivée.

Mesurer l’usage réel avant d’ajouter

Avant de composer une version, regardez ce que les équipes utilisent déjà. Pendo, un éditeur d’outils de mesure d’usage, a publié en février 2019 une étude menée sur 615 comptes clients observés pendant trois mois : en moyenne, 12 % des fonctionnalités d’un logiciel produisent 80 % de son usage quotidien, et 80 % des fonctionnalités sont rarement ou jamais utilisées. L’échantillon est fait de clients de Pendo, venus de secteurs que le rapport énumère, de la banque à la logistique, et le rapport lui-même s’adresse aux éditeurs de logiciels et à leurs investisseurs. Rien n’y dit ce que donnerait un outil interne. Ce qui s’y transpose tient en une phrase : une fonction livrée peut rester inutilisée sans que personne le sache, tant que personne ne mesure.

Un outil interne a un avantage qu’un éditeur n’a pas, ses utilisateurs sont connus par leur nom et joignables dans le couloir. Demandez à votre prestataire de vous sortir, par écran, le nombre d’ouvertures et le nombre d’utilisateurs distincts sur le dernier trimestre. Ce comptage n’existe pas d’office dans un outil, il s’ajoute une fois, et il se lit ensuite à chaque version. Un écran que presque personne n’a ouvert sur le trimestre interroge la demande qui l’a fait naître, et un écran jamais ouvert est un candidat à la suppression. Retirer coûte moins que maintenir : chaque écran qui reste est un écran à vérifier à chaque version, et un écran que personne n’ouvre ne se vérifie jamais, jusqu’au jour où quelqu’un l’ouvre. Le même relevé montre aussi l’inverse, un écran conçu comme secondaire et ouvert plus que tout autre, qui mérite l’attention que la prochaine version allait donner à une nouveauté.

Ce qu’une version emporte avec elle

Une version ne livre pas que du code. Elle emporte les données existantes, qui doivent passer dans le nouveau format sans se perdre, et cette migration se teste en recette sur une copie de la base réelle, jamais sur un jeu d’essai. Elle emporte les procédures internes : une capture d’écran dans un document de formation est fausse dès que l’écran change, et une procédure fausse fait plus de mal qu’une procédure absente, parce que les équipes lui font confiance. Elle emporte la formation, qui pour une version courante tient dans un message qui dit ce qui change et pourquoi, écran par écran, envoyé le jour de la mise en production.

Elle emporte enfin une ligne dans le journal des versions : la date, ce qui a changé, et la demande qui l’a justifié. Ce journal se tient en une ligne par version, et un prestataire qui reprend l’outil y lit pourquoi l’outil est ce qu’il est. Un outil qui a traversé plusieurs versions sans journal est un outil dont personne ne sait plus quelle règle répond à quelle demande, et chaque modification y devient une enquête.

La revue annuelle de votre outil, en cinq questions

Une fois par an, en dehors du rythme des versions, l’outil se regarde en entier, et cette revue tient en cinq questions. Chacune appelle un chiffre ou une liste, et aucune ne se répond de mémoire.

L’usage vient en premier : quels écrans ont été ouverts, par combien de personnes, et lesquels ne l’ont pas été, sur le relevé décrit plus haut lu sur douze mois au lieu d’un trimestre. Vient ensuite ce que l’outil ne tient pas : chaque information que quelqu’un garde en dehors de lui est une demande d’évolution que personne n’a formulée, parce que celui qui a trouvé la parade considère le problème comme résolu. La troisième question regarde devant, vers les dates externes de l’année à venir : une obligation réglementaire, une fin de support annoncée par un éditeur, un logiciel voisin qui va changer et avec lequel l’outil échange des données. Chaque date de cette liste est une adaptation à programmer avant l’échéance, et à placer dans une version.

La liste des refus fait la quatrième : quelles demandes ont été refusées cette année, et lesquelles sont revenues. Reste l’année écoulée en chiffres : ce que les versions ont coûté, rapporté au coût de construction initial, et combien de temps chaque demande retenue a attendu entre son acceptation et sa mise en production. Ces deux nombres sont ceux qui disent si l’outil vieillit. Quand le délai s’allonge d’une année sur l’autre à volume de demandes égal, ou quand une modification d’un écran coûte aujourd’hui plusieurs fois ce qu’elle coûtait à la première version, l’outil est devenu difficile à faire évoluer, et une page de ce site détaille les deux mesures qui remplacent cette impression et les quatre causes qui peuvent la produire.

Trois décisions sortent de cette revue. Le contenu de la prochaine version d’abord, composé de ce que les cinq questions ont fait remonter et non de la file des demandes. L’enveloppe de l’année ensuite, en jours ou en euros, votée avant l’année sur le coût des douze mois écoulés et sur la liste des adaptations datées. Et pour finir la question de savoir si vous continuez sur cette base, ou si l’année qui vient est celle où l’outil se reprend plutôt qu’il ne s’étend. Cette dernière question se pose chaque année, et la réponse est oui jusqu’à l’année où elle cesse de l’être. Sans cette question, la réponse arrive un jour par un devis.

Quelqu’un doit tenir la trajectoire entre deux versions

Tout ce qui précède demande une personne qui connaît le métier et l’outil, qui va voir les demandeurs à leur poste, qui tient la liste des demandes et celle des refus, qui compose les versions et qui prépare la revue annuelle. Dans une entreprise sans équipe technique, ce rôle n’est attribué à personne. Les demandes montent alors jusqu’au dirigeant sans la liste où elles se compareraient, ou jusqu’au prestataire, qui livre ce que vous lui demandez et n’a aucun titre pour refuser une demande de son client.

Les corrections, les montées de version et une enveloppe pour les demandes courantes s’écrivent dans un contrat sur l’outil déjà en service, et une page de ce site en décrit chaque poste, et les trois issues possibles pour chacun. Le tri des demandes, la composition des versions et la question annuelle de continuer ou non demandent en plus quelqu’un qui connaisse votre organisation et dont le retour soit daté d’avance. C’est ce que nous faisons chez nos clients sous la forme d’un référent technique qui revient à date fixe, avec une feuille de route tenue sur douze mois, et la question de savoir sous quel format ce temps de prestataire s’achète a sa propre page. Si votre outil n’a jamais eu de revue, apportez au premier échange la liste des demandes reçues depuis la recette, celles qui ont été livrées et celles qui ont été refusées. Ce premier échange n’est pas facturé. Il part de cette liste, et il peut conclure que la prochaine version de votre outil doit rester vide.

Sources

ISO/IEC/IEEE 14764:2022, Software engineering, Software life cycle processes, Maintenance, ISO/IEC/IEEE, 2022, extrait officiel des définitions (3.1.1 à 3.1.10), https://cdn.standards.iteh.ai/samples/80710/9a26fc3a1a464fa286fb85d6c1eeed31/ISO-IEC-IEEE-14764-2022.pdf

Facturation électronique : guide pratique de démarrage au 1er septembre 2026, Direction générale des Finances publiques, juillet 2026, https://www.impots.gouv.fr/sites/default/files/media/1_metier/2_professionnel/EV/2_gestion/290_facturation_electronique/guide_pratique_facturation_electronique.pdf

The 2019 Feature Adoption Report, Pendo, Suja Thomas, 5 février 2019, https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf