Bonjour,

d'abord je te conseillerais de passer aux dernières versions stables, mais je vais aussi décrire des solutions plus pragmatiques pour que ça marche rapidement... mais sache que tu accumules de la dette technique.
Et last but not least... pourquoi une Hash ?

D'abord, ce mode de pagination est vraiment "très ancien", on ne fait plus comme ça : tu te prives de super fonctionnalités, et peu de gens pourront t'aider si tu continues avec une version de Rails si ancienne. À moins que ta codebase soit énorme et/ou/donc inextricable, je te recommande donc de passer à une version plus récente (Rails 2.3).

Mais dans un premier temps tu peux t'en sortir rien qu'en installant et utilisant une version adaptée de will_paginate : tu ne dois pas avoir tant d'actions et de vues différentes avec la pagination. Je suis quasi-certain qu'il existe des versions de will_paginate pour Rails 1.2.3, j'ai dû en utiliser à l'époque.
Et ensuite, will_paginate gère très bien les collections, tout va bien.

Enfin, il faut aussi voir une chose : le problème du tableau associatif, c'est qu'il n'est pas censé être ordré. En pratique sur des exemples basiques on a assez peu de différences, mais ça change parfois. En imaginant 4 éléments en 2 pages de 2
{:a => A, :b => B, :c => C, :d => D}
tu peux te retrouver à avoir une première requête (page 1)
[[:a,A], [:b,B], [:c,C], [:d,D]] # la page 1 montrera A et B
et une deuxième requête pour la page 2, mais où la collection de départ sera dans l'ordre [A, C, D B] : ton utilisateur aura fait le tour de toutes les pages mais il aura vu deux fois B et aucune fois C, et tu n'y pourras rien !

Donc pourquoi modifier @toto, et surtout en faire une Hash ? Pour une réparation rapide, conserve @toto, et fais une @toto_hash associative, mais un tel souci doit probablement venir d'une incohérence dans la spec, la modélisation ou l'implémentation quelque part...

Pour éviter le problème décrit plus haut, je suppose que tu pourras trouver un critère d'ordre, alors pourquoi ne pas le faire tout de suite ?