Voir un algorithme travailler
Un tri, écrit noir sur blanc, n'est qu'une boucle qui rend un tableau ordonné. Ce que ce code ne montre pas, c'est comment il y parvient : combien de comparaisons, combien de déplacements, et selon quel chemin. En transformant chaque valeur en une barre et chaque opération en une image, je rends ce cheminement visible. On voit la barre comparée surlignée en indigo, la barre déplacée passer en accent, et le tableau se figer progressivement en ambre trié.
Cinq algorithmes, deux familles de complexité
Les touches 1 à 5 (ou T pour faire défiler) basculent entre cinq classiques. Le tri à bulles, par insertion et par sélection sont en O(n²) : le nombre de comparaisons croît avec le carré de la taille du tableau, ce qui se lit à l'œil nu au compteur qui s'emballe. Le tri rapide (quicksort) et le tri fusion (merge sort) tiennent en O(n log n) en moyenne et bouclent en bien moins d'opérations sur le même tableau. Régénérer le jeu de données avec R, puis relancer chaque algorithme sur les mêmes barres, rend cet écart concret : ce n'est plus une notation abstraite, c'est un compteur qui double ou qui reste sage.
Comparaisons et échanges, les deux coûts réels
Un tri se paie de deux façons : les comparaisons (est-ce que cette valeur passe avant cette autre ?) et les déplacements de données (échanges ou écritures). Distinguer ces deux gestes à l'écran est éclairant. Le tri par sélection, par exemple, compare énormément mais échange très peu ; le tri à bulles fait les deux en abondance ; le tri fusion ne « permute » rien mais réécrit des segments entiers. Visualiser ces signatures, c'est comprendre pourquoi le choix d'un algorithme dépend toujours du coût dominant dans le contexte réel — accès disque, mémoire, données déjà presque triées.
Animer sans bloquer : une file d'opérations
Le piège serait d'exécuter le tri d'un bloc puis d'« animer » un résultat déjà
calculé — ou pire, d'insérer des pauses au cœur de la boucle de tri et de geler
l'onglet. J'ai fait l'inverse : chaque algorithme trie une copie du tableau et
enregistre au passage la suite de ses opérations élémentaires
(comparer, échanger, écrire). La boucle de rendu se contente ensuite de rejouer
cette file pas à pas, quelques opérations par image via
requestAnimationFrame. Le calcul et l'affichage sont ainsi
découplés : l'algorithme reste pur et testable, le rendu reste fluide, et la
cadence est réglable sans toucher à la logique de tri.
Ce que ce découplage dit de mes projets
Séparer le quoi (l'algorithme qui produit une suite d'événements) du comment on l'affiche (la boucle qui les rejoue) est exactement le genre de découpage qui fait la différence sur une application réelle : une logique métier isolée, déterministe et couverte par des tests, et une couche de présentation qu'on peut rythmer, instrumenter ou remplacer sans rien casser ailleurs. Pour vous, cela se traduit par un code plus simple à faire évoluer, à diagnostiquer quand une lenteur apparaît, et à reprendre en main par vos propres équipes. La démo est un jouet ; la discipline qu'elle illustre, non.
