Logiciels télécoms

// Le problème

Un FAI régional planifie installations et réparations par téléphone, et les techniciens font rapport par texto : le bureau ne sait jamais où en est un travail ni quel modem est allé chez quel client.

// Ce que nous bâtirions

Un tableau de répartition pour le bureau et une application iOS et Android pour les techniciens, branchés aux systèmes de facturation et d’activation : un travail est assigné, terminé et activé sans un seul appel.

// Ce qu’il comprend

// Technologies

• Next.js
• React Native
• PostgreSQL avec PostGIS
• Interfaces de facturation et d’activation
• AWS

// Le problème

L’équipe de service à la clientèle d’un opérateur répond toute la journée aux mêmes questions de factures, de pannes et de déménagements, et les clients attendent pendant que les cas difficiles dorment dans la même file.

// Ce que nous bâtirions

Un agent dans le clavardage du site et l’application qui répond à partir du contenu d’aide de l’opérateur, vérifie les pannes et explique une facture une fois le client connecté, puis passe la main à une personne avec la conversation jointe. Il utilise un modèle de pointe par son API : le départ le plus rapide pour un produit à fort volume dont le contenu est public et où les consultations de compte passent par des outils que vous contrôlez.

// Ce qu’il comprend

// Technologies

• API d’un modèle de pointe
• Next.js
• PostgreSQL avec pgvector
• Interfaces CRM et facturation
• AWS

// Le problème

Une seule panne produit des centaines d’alarmes sur le réseau, et le centre d’exploitation passe la première heure à trouver la cause première à la main.

// Ce que nous bâtirions

Un modèle sur mesure entraîné sur l’historique d’alarmes et les billets de panne de l’opérateur, qui regroupe les alarmes liées, propose la cause première probable et les clients touchés, et montre à l’équipe pourquoi, servi dans le compte infonuagique de l’opérateur.

// Ce qu’il comprend

// Technologies

• PyTorch
• Kafka
• Python
• Next.js
• AWS

// Le problème

Plusieurs opérateurs régionaux échangent leurs données d’utilisation de gros et d’itinérance en fichiers mensuels, et chaque mois les totaux diffèrent et le litige se règle par courriel.

// Ce que nous bâtirions

Un registre privé à permissions dont chaque opérateur exploite un nœud, où les données d’utilisation et les tarifs convenus sont inscrits au fil des échanges, avec un portail qui montre à chacun les mêmes totaux et signale les écarts tant qu’ils sont petits.

// Ce qu’il comprend

// Technologies

• Next.js
• PostgreSQL
• Hyperledger Besu (privé, à permissions)
• Stockage compatible S3
• AWS

// Le problème

Un fournisseur Internet régional prend les commandes dans son système de facturation, les envoie par courriel à l’équipe réseau pour l’activation et met à jour le dossier client à la main quand le service fonctionne.

// Ce que nous bâtirions

Une intégration qui transmet les nouvelles commandes de la facturation à l’activation, suit chaque étape jusqu’à la mise en service, lance la facturation le bon jour et montre au service à la clientèle où en est chaque commande, en utilisant les Open APIs du TM Forum là où vos systèmes les prennent en charge.

// Ce qu’il comprend

// Technologies

• Node.js
• PostgreSQL
• TM Forum Open APIs
• OpenAPI
• DigitalOcean

// Le problème

Le portail client d’un petit fournisseur repose sur un cadriciel qui n’est plus maintenu ; les paiements échouent de temps à autre, personne n’ose le mettre à jour et les clients appellent au lieu de s’en servir.

// Ce que nous bâtirions

Une récupération qui garde le portail en marche pendant son remplacement : d’abord un examen écrit, les défauts de paiement corrigés tout de suite, puis une reconstruction écran par écran sur une technologie maintenue avec des tests, les comptes clients étant repris sans changement.

// Ce qu’il comprend

// Technologies

• Next.js
• PostgreSQL
• TypeScript
• Playwright
• DigitalOcean