Suite à un diagnostic poussé, il semblerait que le problème provient de la liaison entre le serveur 3CX et les postes utilisateurs lors de la négociation du tunnel TCP en IPv6. L'application ne rétrograde pas en IPv4 en cas de dysfonctionnement. La solution de contournement est d'utiliser l'application WEB pour le moment.
La recherche est en cours sur la ligne internet pour tenter de trouver le dysfonctionnement TCP.
Update 01/07/26 à 14 h Nous avons identifier que 40% du traffic en IPv6 échoue. Ce n'est pas uniquement vers les serveurs 3CX. Le problème semble provenir du coeur de réseau opérateur. Un diagnostic en commun avec l'ingénieur réseau du coeur de réseau est prévu aujourd'hui.
]]>La panne est au niveau de l'opérateur d'interconnexion. Elle est en cours de diagnostique par les ingénieurs.
]]>Retour à la normal
16:00: De nouveau en panne
Le 02/04/2026, 11H30: Plus aucune instabilité constaté sur le site.
]]>Update 8h40
Fin de problème. Le docker qui sert de firewall applicatif ne s'était pas redémarré.
]]>Update 19 h
L'électricité est de retour.
]]>Udate 10 h 10
Le runner ne semble plus avoir de problème après redémarrage de Gitlab. Nous restons en observation.
]]>Après redémarrage du service Java, l'application semble beaucoup plus stable.
]]>Incident résolu à 10 h
]]>Le problème est le même que hier
En attente de OVH pour la correction.
OVH a corrigé le problème logiciel. Tout semble fonctionner correctement désormais. En observation.
Nouvelle correction par OVH ce matin, en observation.
]]>Le problème est lié à OVH. Incident en cours sur le cluster où est hébergé le site : https://web-cloud.status-ovhcloud.com/incidents/xrv6pfd3rym7
Incident corrigé chez OVH. Il s'agissait d'un problème réseau. En observation.
Incident terminé chez OVH.
]]>Le 1812 à 14 h 30
Fin de migration.
]]>Le problème vient des fichiers trop volumineux pour être envoyés sur le cloud. Mise en place d'une config pour découper les backups.
Maj déployé. En observation pour vérifier si l'incident est terminé.
La maintenance n'a pas fonctionné. En recherche de solutions.
Le serveur a été redémarré. Dans le doute, reboot.
Impossible de savoir pourquoi Gitlab n'est pas en mesure d'envoyer sur S3. Toujours pas fonctionnel. Nous avons mis en place un script type rclone pour envoyer les sauvegardes sur S3 avec une méthode externalisé à Gitlab.
Le 17/12 : Vérification OK. Le dernier backup a bien été uploadé sur S3 via le script externe. La solution de contournement externe est fonctionnelle. Fin de l'incident.
]]>