Ralentissement jusqu'a perte de connexion

Deducing from about 20,000 manual blocklist entries for domains like r11.sn-qxoedn7z.googlevideo.com, your debug log suggests you would be using a third-party script with the intention of blocking Youtube ads.

While Pi-hole itself would update its gravity database once per week, that script would be applying frequent updates of Pi-hole's gravity database, presumably triggered by adding newly detected YT domains to Pi-hole's blocklist immediately upon detection.

Those updates may become harmful if the script would trigger another update or even series of updates while the previous hasn't yet finished and still locks database access.

This is likely what is happening on your system and what would be causing excessive load on your system:

*** [ DIAGNOSING ]: contents of /var/log

-rw-r--r-- 1 pihole pihole 37K May  6 10:57 /var/log/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2022-05-06 00:45:09.658 20869/T20876] WARNING: Long-term load (15min avg) larger than number of processors: 41.1 > 1
   [2022-05-06 00:45:10.964 20869/T20876] add_message(type=6, message=excessive load) - SQL error step DELETE: database is locked
   [2022-05-06 00:45:10.965 20869/T20876] Error while trying to close database: database is locked
   [2022-05-06 00:50:09.099 20869/T20876] WARNING: Long-term load (15min avg) larger than number of processors: 41.3 > 1
   [2022-05-06 00:50:10.204 20869/T20876] add_message(type=6, message=excessive load) - SQL error step DELETE: database is locked
   [2022-05-06 00:50:10.204 20869/T20876] Error while trying to close database: database is locked

It would be prudent to test the database for its locking status and defer any updates for a certain amount of time before trying anew, collecting and queueing any additionally detected YT domains in the meantime.

You'd have to address this with the third-party script maintainer.

In the meantime, as the time it takes to upgrade the database correlates with the total number of domains already stored (~<1.4 millions in your case), you could try to reduce your database size in order to reduce the risk of parallel updates.
You probably could remove some of the older blocked YT domains, and you could consider to run yubiuser's adlists tool to learn about your actual blocklist utilisation, and use those insights to trim down your block lists to the ones that are most applicable for your browsing behaviour.

As a general advice, I wouldn't recommend to try and block YT ads by means of DNS filtering. YT delivers ads via the same domains as its content, and this cannot be addressed satisfactorily by a DNS filter.
Besides the issues this may cause in cases like yours, you always run the risk of blocking wanted content along with unwanted (as YT obviously keeps swapping domains). Any DNS filter can only deal with domains - for same domain content, a browser-based extension is better equipped to block resources at the URL level.

From that point of view, you could also consider to remove that third-party script altogether.