(I’m answering in English as my French is a bit poor - but don’t hold back to respond in French; I can read it enough or machine translate it)
First of all, I’m not much involved with Geovisio, so I might write wrong things. Please correct me if this happens.
I’m imagining that a server holds imagery, uploaded by contributors.
The first choice to make is: should every server hold all images? I.e. if picture ‘123’ is uploaded to server ‘A’, should server ‘A’ forward the picture to ‘B’, ‘C’ and ‘D’? The advantage is that all pictures will be preserved, even if a server topples. However, this means that every server should have a lot of resources.
The second choice is the opposite: server ‘A’ only holds pictures from it’s contributors, server ‘B’ holds a separate set of pictures. The client applications query all servers that they know of and mix the results.
At last, there are many mix-forms possible, e.g. if I ask server ‘A’ for pictures in a certain region, it might query server ‘B’ and ‘C’ as well. It might cache those pictures (temporarily or forever).
Another in-between form would be that servers can hold some pictures for other instances too - providing some redundancy. (E.g. servers ‘B’, ‘C’, ‘D’ and ‘E’ could all hold a quarter of the pictures of ‘A’, meaning there is a full backup). If this is wanted, then IPFS might be worth looking into.
That being said - I’m very fond of ActivityPub as well. This might be a second form of federation: namely to update other servers of the fact that Contributor X uploaded some pictures to server A. This might even draw an audience, as MapComplete (bot) (@mapcomplete@botsin.space) - botsin.space proves 
Another aspect is indeed that of account management. Should I be able to login into server ‘B’ with ‘pietervdvn@serverA.fr’?
The problem of duplicate images can be fixed by hashing the (input) image. This hash will provide good duplicate-image detection.
