Tick-Tock : La stratégie pour éviter que votre logiciel ne plante

Salut, tout le monde ! Aujourd’hui, je veux partager une stratégie qui a profondément changé ma manière de penser l’évolution du logiciel. Je l’ai mise en pratique lorsque je travaillais chez Woovi, une fintech brésilienne spécialisée dans les paiements Pix, et elle est depuis devenue l’une de mes boîtes à outils mentales les plus précieuses.

Je parle de la stratégie Tick-Tock.

Le Problème : Fonctionnalité après fonctionnalité

Imaginons que vous travaillez sur un produit qui croît rapidement. Chaque sprint apporte une nouvelle fonctionnalité, chaque semaine voit des changements dans la base de données, chaque version introduit une nouvelle API. Ça semble productif, non ?

Faux. En pratique, ce qui se passe, c’est :

• La base de données devient un Frankenstein de migrations
• Les API anciennes se cassent sans avertissement
• Les clients qui s’intègrent à vous craignent de mettre à jour
• L’équipe accumule une dette technique jusqu’à ne plus pouvoir la supporter
• Quelqu’un effectue un déploiement le vendredi et tout casse

Vous connaissez cette sensation de courir dans un train tout en changeant les roues ? Exactement.

Qu’est-ce que Tick-Tock ?

La stratégie Tick-Tock est née à l’origine chez Intel, qui l’utilisait pour faire évoluer ses processeurs. L’idée est simple : alterner entre deux types de cycles.

Tick (Stabilisation)

• Concentration sur la maintenance, les corrections et la refactorisation
• Aucun changement dans les API publiques
• Améliorations de performance et de code
• Paiement de la dette technique
• Le client n’a rien à modifier de son côté

Tock (Innovation)

• Nouvelles fonctionnalités, nouvelles API
• Évolution du produit
• Changements pouvant nécessiter une adaptation du client
• Expérimentation contrôlée

Le principe est : jamais deux tocks d’affilée. Chaque fois que vous lancez quelque chose de nouveau (tock), le cycle suivant est une phase de stabilisation (tick). Toujours.

Comment Woovi applique cela

A Woovi, on traitait de l’argent. Littéralement. Paiements Pix, intégrations avec de multiples prestataires bancaires, webhooks en temps réel. Il ne fallait pas que ça casse. Un seul bug pouvait empêcher un client de recevoir un paiement.

La stratégie Tick-Tock apparaissait à plusieurs niveaux :

Modifications dans la base de données

Ceci est peut-être l’application la plus cruciale. Quand on travaille avec une base de données en production, la règle d’or est : ne faites jamais une migration destructive d’emblée.

Imaginons que vous devez renommer un champ de pixKey en dictKey. La mauvaise approche :

// Tock direct (va casser)
Migration 1: Renomme pixKey → dictKey
// Tout ce qui dépendait de pixKey casse instantanément

La manière Tick-Tock :

// Tock: Ajoute le nouveau champ
Migration 1: Ajoute champ dictKey
Migration 2: Script qui copie pixKey → dictKey

// Tick: Stabilise
Migration 3: Le code lit désormais à partir de dictKey (avec fallback vers pixKey)
Les tests confirment que tout fonctionne avec les deux champs

// Tock: Évolue
Migration 4: Le code utilise uniquement dictKey
Migration 5: Supprime pixKey (seulement après avoir confirmé que personne ne l’utilise)

Vous voyez ? Chaque étape est sûre. Si quelque chose tourne mal à n’importe quelle étape, vous pouvez revenir en arrière sans perdre de données.

Évolution des fonctionnalités

Quand il fallait modifier le comportement d’une fonctionnalité, ce n’était jamais « changer et basta ». C’était toujours :

1. Tock : Lancer la nouvelle version à côté de l’ancienne
2. Tick : Surveiller, corriger les bugs, s’assurer que les clients ont migré
3. Tock : Supprimer l’ancienne version (si l’on est sûr que personne ne l’utilise)

Dans la pratique, cela signifiait que le système supportait deux versions en même temps pendant une période donnée. Est-ce que cela demandait plus de travail ? Oui. Mais le coût de casser un client en production était bien plus élevé.

APIs et rétrocompatibilité

Cela vaut particulièrement pour les API publiques. Chez Woovi, nous faisions de la rétrocompatibilité une priorité. Si vous aviez besoin de modifier un endpoint :

• Tick : Ajoute le nouveau champ dans la réponse sans retirer l’ancien
• Tock : Documente la dépréciation, donne un délai au client pour migrer
• Tick : Surveille qui utilise encore l’ancien champ
• Tock : Supprime l’ancien champ (avec préavis)

L’idée est que le client ne se réveille jamais avec une intégration cassée. Il dispose de temps, de documentation et de support pour migrer à son propre rythme.

Pourquoi cela fonctionne

La beauté du Tick-Tock, c’est qu’il résout simultanément plusieurs problèmes :

Pour l’ingénierie :

• La dette technique ne s’accumule jamais trop parce qu’il y a un cycle dédié pour cela
• Les déploiements sont plus sûrs car il n’y a jamais de changement majeur sans stabilisation ensuite
• L’équipe ne s’épuise pas dans un sprint sans fin

Pour le produit :

• Les nouvelles fonctionnalités ont le temps d’être polies avant le prochain lancement
• Les retours des utilisateurs sont intégrés dans les cycles de tick
• La qualité perçue du produit augmente

Pour le client :

• Les mises à jour ne cassent jamais l’intégration
• Les clients plus prudents peuvent rester sur les ticks et sauter les tocks
• La documentation et la migration font partie du processus, et non une réflexion après coup

Appliquer cela à votre projet

Vous n’avez pas besoin de travailler dans une fintech pour utiliser Tick-Tock. La stratégie fonctionne dans n’importe quel contexte :

1. Définissez vos cycles : cela peut être par sprint, par mois ou par release. L’important est d’alterner.
2. Soyez discipliné sur les ticks : la tentation d’ajouter « juste une autre feature » dans le cycle de stabilisation est énorme. Résistez.
3. Documentez tout : chaque tock doit avoir un plan de migration clair. Chaque tick doit avoir des métriques de stabilité.
4. Communiquez clairement : votre équipe et vos clients doivent savoir dans quelle phase vous êtes.

En résumé

	Tick	Tock
Focalisation	Stabilité et maintenance	Fonctionnalités et innovation
APIs	Aucun changement	Possibilité d’ajouter/modifier
Base	Migration de compatibilité	Migration d’évolution
Risque	Faible	Contrôlé
Client	Rien à faire	Peut nécessiter une adaptation

La stratégie Tick-Tock n’est pas une invitation à aller lentement. C’est une façon d’avancer constamment vite sans laisser derrière soi une traînée de destruction. Chez Woovi, c’était ce qui nous permettait de faire évoluer un système financier critique sans jamais briser l’expérience des clients.