Il y a de nombreuses approches possibles tout dépend de comment on regarde sa machine à état - systeme global ou chacun des sous systèmes comme étant considérés comme indépendants. ça ne change pas le tuto.
Quand vous proposez
void loop()
{
gereRTC();
gererBouton();
gererPompe();
gererLed();
gereLCD();
}
Vous isolez les systèmes mais en mélangeant des concepts - c’est une approche possible dans laquelle gereLCD() finalement est dépendant de ce que vous avez fait avant et vous perdez potentiellement en granularité - aucune possibilité d’afficher une transition d’état ou des sous évènements si vous ne voulez pas mettre de code LCD dans les autres fonctions
Pour conserver une approche système global / machine à état, la loop doit vérifier les générateurs d’évènements et déclencher les bonnes fonctions. par exemple la librairie oneButton (qui est une machine à états) on la déclenche en début de loop pour identifier un évènement appui, ça pourrait être votre gereBouton() mais ensuite il faudrait juste rajouter un gereTiming() qui est un autre facteur d’évènements. Il n’y a pas plus de soucis à solliciter la RTC 100 fois par seconde que de lire millis() plusieurs milliers de fois ou la température ou la valeur d’une pin.c’est fait pour cela...
Perso dans ce cas comme le timing est approximatif sans contrainte temps réel forte, j’utiliserais (en plus de vérifier les boutons) millis() pour le déclenchement d’un évènement toute les x secondes, et regarderai la possibilité d'événement Déclenché directement par une RTC 3231 comme interruption externe. ce sont les 3 évènements possibles sur le système.
je structurerais le code de simpleClick() avec des fonctions pour que la partie potentiellement dupliquée sur le timing ne soit pas redondante
Mais bien sûr comme toujours il n’y a pas qu’une seule approche possible, l’important c’est de conserver une logique et structuration propre en évaluant aussi la conséquence de ses choix sur la faisabilité de certaines fonctions attendues