LIQAA : comment nous avons construit une plateforme de visioconférence algérienne, et ce que nous avons appris en la cassant

Cinq minutes perdues avant que la réunion ne commence

Demandez à n'importe quelle organisation algérienne comment s'est passée sa dernière visioconférence, et vous entendrez la même histoire. L'un télécharge une application, un autre crée un compte et attend l'e-mail de confirmation, un troisième cherche le code dans une vieille conversation. Puis la discussion commence, et le compteur s'arrête à la quarantième minute.

La qualité est rarement le problème. Le problème, c'est la friction.

Chaque étape entre le lien et la salle fait perdre une partie des participants, et une réunion qui démarre incomplète ne se rattrape pas. C'est pourquoi la première décision de conception de LIQAA a été de réduire le parcours, du clic au son et à l'image, à deux étapes seulement : vous ouvrez le lien, vous tapez votre nom, vous entrez.

L'invité n'installe rien et ne crée aucun compte. Le navigateur avec lequel vous lisez cet article suffit. Celui qui crée la réunion peut avoir besoin d'un compte s'il veut enregistrer ou facturer au temps ; celui qui la rejoint, non.

• La salle fonctionne dans le navigateur via WebRTC, sur ordinateur comme sur téléphone.
• Le lien, c'est l'invitation.
• 3 heures par réunion dans l'offre gratuite, pas 40 minutes.
• Arabe, français et anglais, avec une interface qui respecte l'écriture de droite à gauche.

La panne qui a duré huit jours et nous a appris à superviser

Revenons à la caméra. Nous avions unifié les en-têtes de sécurité de tous les sites de l'écosystème dans un seul fichier de configuration. Ce fichier avait été écrit pour des sites de contenu, et il contenait une ligne qui interdisait l'accès à la caméra et au microphone. Il a été appliqué à LIQAA aussi.

Résultat : le navigateur refusait `getUserMedia` avant même d'afficher à l'utilisateur la moindre demande d'autorisation. Aucun message d'erreur visible, rien qui semblait en panne. La page répondait 200, et la supervision, qui demande « la page répond-elle ? », répondait oui.

Une plateforme vidéo incapable d'allumer une caméra, et tous les indicateurs au vert.

Nous avons corrigé la ligne en quelques minutes. Mais la vraie leçon n'était pas dans la correction. Une sonde qui interroge le code de statut ne mesure pas un produit ; elle mesure que le serveur web est vivant. Nous avons donc construit une sonde qui fait autre chose : toutes les dix minutes, elle ouvre une vraie salle, demande un jeton d'accès, fait entrer un participant réel, vérifie que la politique d'accès à la caméra l'autorise toujours, puis ferme la salle. Si une seule condition échoue, nous recevons une alerte.

Nous racontons cette histoire dans un article marketing à dessein. Celui qui vous dit que son produit n'est jamais tombé en panne est soit tout nouveau, soit ne mesure rien.

Pourquoi un SFU plutôt qu'une connexion directe entre appareils

La façon la plus simple de construire un appel vidéo est que chaque participant envoie son flux directement à chacun des autres. Cela fonctionne bien à deux. À dix, chaque appareil doit envoyer neuf flux en même temps : la liaison montante sature et la batterie chauffe avant la fin d'une phrase.

LIQAA repose sur une architecture SFU (Selective Forwarding Unit, unité de transfert sélectif), basée sur LiveKit en version 1.10. Chaque participant envoie son flux une seule fois au serveur, et le serveur le redistribue. Pas de décodage ni de réencodage de son côté : uniquement du relais.

Conséquence pratique : le coût croît linéairement avec le nombre de participants, et non de façon quadratique. C'est pourquoi une salle peut accueillir cent personnes sur un seul serveur sans que personne ne doive changer d'appareil.

Simulcast : pourquoi le réseau le plus faible n'impose pas sa loi à la salle

Cette technique fait la différence entre une réunion qui fonctionne en Algérie et une réunion qui fonctionne en démonstration.

Le participant envoie simultanément deux ou trois versions de sa vidéo à des qualités différentes. Le serveur choisit ensuite, pour chaque destinataire, la version adaptée à son propre réseau, et non au réseau de la salle.

Sans cette technique, il se passe ce que tout le monde connaît : une seule personne a une connexion faible, et la qualité baisse pour tous. Avec Simulcast, cette personne reste dans l'appel avec une version légère, tandis que les autres voient la version haute qualité. Au même moment, dans la même salle.

Les codecs pris en charge sont VP8, H.264, VP9 et AV1, choisis selon ce que chaque appareil supporte. Par-dessus fonctionne GCC, qui mesure la latence et la perte de paquets et ajuste le débit avant que les saccades n'apparaissent, et non après.

Le réseau algérien en particulier : CGNAT et ports bloqués

Dans WebRTC, les médias privilégient UDP pour sa faible latence. Mais de nombreux réseaux d'entreprise et d'hôtel bloquent complètement UDP, et les réseaux mobiles placent l'utilisateur derrière un CGNAT, si bien qu'il ne dispose pas d'une adresse publique propre.

Nous utilisons une plage de ports UDP de 50000 à 60000 pour les médias, et une voie de secours en TCP via le port 7881. Si UDP est bloqué, la négociation bascule sur TCP au lieu de laisser tomber la connexion. Des serveurs STUN servent à découvrir l'adresse publique derrière le NAT : c'est ce qui permet à un utilisateur 4G derrière un CGNAT d'établir le chemin, car la connexion part de chez lui vers l'extérieur, ce que ces réseaux autorisent.

Quant à la signalisation, c'est-à-dire l'échange des informations de connexion avant le démarrage des médias, elle passe par un WebSocket chiffré sur le port 443. Le même port que celui avec lequel vous ouvrez n'importe quel site : le réseau de l'entreprise n'a rien de plus à ouvrir.

Et voici la limite, que nous énonçons clairement : les réseaux qui n'autorisent que TCP sur le port 443, exclusivement à travers un proxy obligatoire, restent le cas le plus difficile pour n'importe quelle plateforme vidéo au monde. Celui qui vous promet que son produit fonctionne sur tous les réseaux de la planète n'a pas mesuré.

Le chiffrement : où il a lieu et ce que cela signifie pour vous

Chaque connexion est chiffrée au niveau du transport via DTLS-SRTP. C'est imposé par WebRTC et ne peut pas être désactivé. Quiconque se trouve sur le réseau entre vous et le serveur — fournisseur d'accès, réseau du café ou personne qui partage votre Wi-Fi — ne voit que des paquets chiffrés, ni son ni image.

En plus, la plateforme prend en charge le chiffrement de bout en bout au niveau de la trame via Insertable Streams avec AES-GCM. La trame est chiffrée dans le navigateur de l'émetteur avant de le quitter, et n'est déchiffrée que dans le navigateur du destinataire. Dans ce mode, le serveur relaie des paquets qu'il est lui-même incapable de lire.

Pourquoi entrer dans ces détails ? Parce que le mot « chiffré » est écrit partout, et qu'on désigne ainsi le premier cas seulement. La différence tient à une seule question : l'opérateur de la plateforme peut-il, s'il le voulait ou s'il y était contraint, écouter ? Avec le chiffrement de bout en bout, la réponse est non, car la clé n'est jamais passée par lui.

La capacité : ce que nous avons mesuré, pas ce que nous espérons

Nous avons réalisé un test de charge avec l'outil officiel de LiveKit, avec des participants qui publient de la vidéo et s'abonnent aux flux des autres. Un véritable appel, pas des connexions vides.

Sur le serveur actuel à 12 cœurs : 20 participants ont consommé environ 8 % du processeur, 50 environ 12 %, 100 environ 23 % et 200 environ 25 %. À 500 participants, le pic a atteint environ 47 %, avec zéro erreur et zéro coupure.

Une remarque sur l'honnêteté de ce chiffre : le simulateur fait tourner tous les participants sur la même machine, et encode et décode donc tous les flux localement. Une grande partie de cette consommation revient ainsi au simulateur et non au serveur, et la capacité réelle du serveur seul est supérieure à ce qui apparaît.

En pratique : une salle de formation de cent stagiaires n'est pas un cas exceptionnel qui demande une préparation particulière.

• 100 participants : environ 23 % du processeur.
• 500 participants : pic d'environ 47 %, avec zéro erreur.
• Limite appliquée selon l'offre : 100, 300 et 500 participants.

L'enregistrement se fait sur le serveur, pas sur l'appareil de quelqu'un

Beaucoup de solutions appellent « enregistrement » ce qui n'est qu'une capture d'écran depuis le navigateur d'un participant : on lui demande de partager son écran, et un fichier atterrit dans son dossier de téléchargements. Ce fichier dépend de son appareil, de son réseau et de sa présence dans la salle, et rien n'en parvient au compte.

Chez nous, l'enregistrement se fait sur le serveur via le service Egress de LiveKit. La mise en page de la salle est composée et encodée en fichier MP4 au format H.264, indépendamment de l'appareil de tout participant. L'hôte peut partir ou perdre sa connexion : l'enregistrement continue.

Et un détail que nous jugeons plus important que la fonctionnalité elle-même : l'indicateur qui informe les participants qu'un enregistrement est en cours n'est accepté que de la part de l'hôte. Dans une conception moins attentive, n'importe quel participant pourrait afficher un faux avertissement d'enregistrement, ou masquer un enregistrement réel. C'est une question de consentement, et elle est tranchée côté serveur, pas dans l'interface.

La salle de consultation : une réunion facturée à la minute

Cette fonctionnalité transforme la réunion d'un coût en revenu, et nous ne connaissons aucune autre plateforme qui la propose sur le marché algérien.

Le médecin, l'avocat ou l'enseignant fixe un tarif à la minute en dinars et obtient deux liens : un pour lui, un à envoyer à son client. Le compteur ne démarre pas d'un clic, mais au moment où deux personnes sont réellement connectées dans la salle. Une personne qui attend seule, ce n'est pas une consultation.

Il s'arrête à la fin de la salle. Le consultant n'appuie sur rien, et ne peut donc pas oublier d'arrêter le compteur et facturer à son client ce qu'il n'a pas consommé. Nous avons testé exactement ce cas : une salle à 500 DA la minute, une personne seule, le compteur n'a pas démarré ; puis la seconde est arrivée et il a démarré ; la salle s'est terminée après quatre-vingt-quatorze secondes, et le décompte a été clôturé à deux minutes pour un montant de 1 000 DA.

Les minutes sont arrondies à la minute supérieure, car une minute et dix secondes, ce sont deux minutes de la journée de travail de quelqu'un.

• Tarif à la minute en dinars algériens.
• La facturation démarre quand le second participant est réellement là.
• Aucun bouton à oublier.
• Un décompte clair à la fin : minutes, montant et statut du paiement.

Qui contrôle la salle

Dans de nombreuses applications, les « commandes de l'hôte » sont des messages que son navigateur envoie aux autres navigateurs, qui y obéissent. Le problème, c'est que n'importe quel participant peut envoyer le même message, et donc exclure ou couper le micro d'un autre, car personne ne vérifie qui l'a envoyé.

Chez nous, l'exclusion et la coupure du micro sont exécutées sur le serveur via l'API de LiveKit, et ne le sont que pour celui qui détient la clé d'hôte, délivrée à la première personne qui ouvre la salle. La personne exclue n'est pas priée de partir : elle est déconnectée.

Et l'identité de chaque participant est attribuée par le serveur, pas par le client. Le nom affiché est celui que l'utilisateur a saisi, tandis que l'identité interne porte un suffixe aléatoire. Cela évite deux problèmes : deux personnes qui tapent « Mohamed » et dont l'une exclut l'autre sans que ni l'une ni l'autre ne comprenne ce qui s'est passé, et un imposteur qui se fait passer pour l'hôte afin d'hériter de ses droits.

Le mot de passe de la réunion et la salle d'attente sont eux aussi imposés par le serveur. Qui ne connaît pas le mot de passe n'obtient même pas de jeton d'accès, et qui entre en salle d'attente y reste jusqu'à ce que l'hôte l'admette.

Un agent d'IA qui ouvre une salle pour vous

Le protocole MCP est la norme qui relie désormais les modèles d'intelligence artificielle aux outils réels. LIQAA exploite son propre serveur MCP, inscrit au registre officiel du protocole sous le nom io.liqaa/meetings.

Concrètement : vous dites à votre assistant IA « ouvre-moi une salle de réunion », il la crée et vous donne le lien. Sans navigateur et sans compte. Les outils disponibles comprennent la création d'une salle instantanée, la consultation des offres et de leurs limites, la consultation de la capacité de la plateforme et des statistiques publiques agrégées.

Pourquoi est-ce important ? Parce qu'une réunion que l'on peut ouvrir depuis un flux de travail automatisé permet qu'une prise de rendez-vous aboutisse à une salle prête, ou qu'un ticket de support aboutisse à un appel, sans étape humaine intermédiaire.

Qu'une plateforme algérienne figure dans ce registre dès aujourd'hui n'est pas un détail. Les règles de cette course s'écrivent maintenant.

Les offres

L'offre gratuite n'est pas un échantillon. Cent participants par réunion, trois heures par réunion, un nombre illimité de réunions, et sans carte bancaire.

À titre de comparaison, la limite gratuite courante dans le monde est de quarante minutes. C'est la limite qui coupe un cours en plein milieu et oblige tout le monde à revenir avec un nouveau lien.

L'offre Professionnelle, à 2 900 DA par mois, porte la salle à 300 participants et supprime la limite de durée. L'offre Entreprise, à 9 900 DA par mois, va jusqu'à 500 participants. Le paiement se fait en dinars par carte EDAHABIA ou CIB.

Les prix évoluent : la page des tarifs sur liqaa.io fait toujours foi.

Pour qui nous l'avons construite

Les centres de formation et l'enseignement à distance. Une séance pour cent stagiaires avec un seul lien, et trois heures qui suffisent pour une séance complète sans coupure. Et pour qui veut couronner la formation d'un certificat vérifiable publiquement, c'est ce que propose AlgeriaCertify au sein du même écosystème.

Les médecins et la télésanté. Un patient d'une autre wilaya entre dans une salle chiffrée via un lien, et la consultation est facturée à la minute. Aucune application à installer, aucun compte à créer.

Les professions libérales. Avocat, ingénieur, comptable, consultant : quiconque vend son temps peut transformer la réunion en un service au prix affiché.

Les organisations et les équipes distribuées. Des réunions internes sans licence par employé, un enregistrement côté serveur pour les absents, et un véritable contrôle sur qui entre et qui prend la parole.

Comment démarrer

Ouvrez liqaa.io et cliquez sur « Démarrer un appel ». Une salle s'ouvre avec un lien unique. Copiez-le et envoyez-le par WhatsApp ou par e-mail. Qui l'ouvre tape son nom et entre.

Si vous voulez une réunion planifiée, un enregistrement ou une salle de consultation facturée à la minute, créez un compte gratuit. Les invités restent sans compte dans tous les cas.

Et si vous êtes développeur, la plateforme expose une API et un serveur MCP, et une salle peut être intégrée à votre application. Commencez par liqaa.io/mcp et par la section développeurs de tkawen.com.