Les retours arrière peuvent prévenir ou manager des problèmes d’état défectueux.

Rollback: A Tried-and True Way to Make Sure Your Product or Site Still Works Par Johanna Rothman

https://www.jrothman.com/mpd/2026/05/rollback-a-tried-and-true-way-to-make-sure-your-product-or-site-still-works/

Si vous êtes comme moi, vous utilisez des applications et des sites web au travail chaque jour. À quelle fréquence ces applications et sites tombent-ils en panne ? Bien trop souvent.

Quand cela est possible, je signale le problème. Combien de temps faut-il pour le résoudre ? Parfois, il faut des jours à ces fournisseurs pour réparer leur site. Je ne m’attends qu’à dix à quinze minutes car je m’attends à ce qu’ils utilisent le retour arrière (rollback), plutôt qu’un développement et déploiement rapides.

Le retour arrière n’est pas nouveau — c’est une idée éprouvée depuis au moins les années 1980. En tant qu’industrie, nous savons que les nouvelles livraisons peuvent casser ce qui fonctionnait auparavant. Ce n’est pas grave. Nous pouvons revenir à une version déjà connue comme bonne. Aura-t-elle les nouvelles fonctionnalités ? Non. Mais il n’y aura pas les problèmes :  le produit ou le site web fonctionnera toujours. C’est pour ça que les retours arrière fonctionnent.

Mon histoire avec les retours arrière.

Quand j’ai commencé à programmer dans les années 1970, nous n’avions pas de contrôle de version. Nous notions qui avait modifié ce fichier par un « MRU » (Mise à jour la plus récente / Most Recently Updated). Cela nous permettait soit de nous demander ce que nous avions bien pu faire, soit de demander à celui ou celle qui avait modifié le code.

C’est possiblement une identification de version. Ce n’est pas un contrôle de version.

J’ai utilisé le contrôle de version pour la première fois au début des années 1980 : d’abord SCCS, puis RCS. C’étaient des outils lourds, mais ils nous permettaient de marquer les bonnes versions connues. C’était essentiel pour pouvoir revenir en arrière lorsque nous avons introduit des problèmes où que ce soit : dans le produit ou lors du déploiement.

Je suis passée au management de projet au milieu des années 1980. C’est alors que j’ai réalisé cette idée importante :

L’installation est la première chose que le client voit. C’est la première interaction client avec le produit. Faisons en sorte que cette interaction soit agréable.

Si l’installation n’est pas facile, le client est déjà enclin à détester le produit. Dans les années 80, mes chefs de produit se concentraient sur les fonctionnalités que le produit était censé avoir. Cela allait, sauf que les chefs de produit n’ont pas pris en compte l’installation. Ils supposaient que les développeurs « se chargeraient » eux-mêmes de l’installation.

Les développeurs sont aussi humains. Ils ne voulaient pas se concentrer sur l’installation qui n’était pas un problème « difficile » à résoudre. Pourtant, trop souvent, j’ai travaillé sur des produits dont les procédures d’installation et la documentation étaient très médiocres.

C’est pourquoi j’ai concentré une partie de mon travail de management de projet sur la facilité d’installation du produit. Je voulais que les clients aient une bonne interaction dès le départ.

Mais l’installation et l’ajout de fonctionnalités supplémentaires ne sont qu’une partie de l’équation. La deuxième partie est de s’assurer de ne pas laisser le client dans une mauvaise passe. C’est là l’intérêt du retour arrière.

Les retours arrière peuvent prévenir ou manager des problèmes d’état défectueux.

Que se passe-t-il quand l’installation ne marche pas, d’une manière ou d’une autre ? Ou échoue en cours de route ? Ou, comme je l’ai trop souvent constaté ces dernières semaines, le site est dans un état corrompu ou compromis et l’utilisateur ne peut pas faire ce qu’il veut ?

C’est une expérience utilisateur terrible. Je suis beaucoup moins intéressée à continuer d’utiliser le site s’ils ne peuvent pas le maintenir pour des activités normales.

Appliquez un retour arrière.

Lorsqu’un produit ou un site fait l’objet d’une procédure de retour en arrière, le fournisseur devrait pouvoir restaurer depuis cet endroit connu en peu de temps. À quel point ? Dans les années 80, je voulais que ce soit 10 minutes, maximum. Pourquoi serait-ce différent maintenant ?

Je peux entendre tous les développeurs parler de mises à jour de bases de données, de déploiements à sens unique, etc. Je comprends la nécessité d’aller de l’avant. Et, je vous mets au défi : testez à fond l’installation et le produit avant de faire une mise à niveau à sens unique. Sinon, rendez facile le retour arrière.

Parce que si ce n’est pas le cas, et que je dois restaurer mes données de la façon dont votre produit les a détruites, je trouverai un remplaçant à votre produit.

Et si ce n’est pas le cas, et que je n’utilise « que » votre site web ? Je trouverai un moyen de me plaindre et/ou de trouver un remplaçant pour votre produit.

Les problèmes sur l’état de votre produit ne sont pas la faute de l’utilisateur. Ils sont la faute du vendeur ou du producteur. Pire encore, la plupart de ces problèmes résultent d’un manque de tests.

Nous avons besoin de plus de tests, pas de moins.

J’espère que vous souhaitez que votre produit ou site web continue de fonctionner, même face à des situations étranges. N’oubliez pas, les lignes de code ne sont pas un capital. Le nombre de tests n’est pas un atout. Mais des tests qui mettent à l’épreuve l’installation de votre produit ou les mises à jour de votre site ? Ce sont des atouts de valeur tout autant que des fonctionnalités testées et en cours d’exécution. (Parce que les tests sont la façon dont on arrive à exécuter des fonctionnalités testées.)

Je veux des produits et des sites web modernes. Mais je ne les veux que quand ils fonctionnent.

C’est pourquoi tous les producteurs doivent réfléchir à la manière dont ils reviendront à un état de bon fonctionnement déjà connu.

Ne m’envoyez pas un e-mail pour aller sur votre site sans tenir la promesse de vos fonctionnalités. C’est un défaut d’installation. Ces défauts d’installation brisent la confiance de vos utilisateurs, à la fois pour vous en tant que producteur et pour les problèmes que vous prétendez résoudre pour vos utilisateurs.

Corrigez cela avec davantage de tests et ajoutez une procédure de retour arrière. Le retour arrière vous donnera un peu de répit pour résoudre les problèmes sans que vos utilisateurs ne vous crient dessus.

Parce que oui, lorsque vous rompez la promesse sur les problèmes que vous résolvez, vos utilisateurs chercheront une alternative. Rappelez-vous, les managers ne veulent pas de clients qui les quittent. Les managers veulent un chiffre d’affaires et une fidélisation de clients toujours plus élevés.

Les retours arrière sont une méthode éprouvée pour faire fonctionner votre produit ou site. Apprenez à utiliser les retours arrière et davantage de tests pour satisfaire vos utilisateurs et managers. Rappelez-vous, c’est la première chose que vos clients voient.