Aller au contenu
~/ projects / / api-lms-sans-interface

API LMS sans interface

Un système de gestion de l'apprentissage flexible et orienté API pour le secteur éducatif guinéen.

· Idea ·
Guinée EdTech API Éducation LMS
project.json
// project overview
"status": "idea",
"tags": ["guinée", "edtech", "api", "éducation", "lms"],

Ce que je vois

Je vends des laptops à des étudiants via Kalinko Store. Chaque semestre, de plus en plus d’étudiants à Conakry repartent avec une machine sous le bras. Le problème matériel se réduit. Le problème logiciel, non.

La majorité des écoles fonctionnent encore avec des cahiers de registre et des groupes WhatsApp. Les rares qui ont numérisé ont acheté des plateformes rigides conçues pour des contextes qui ne ressemblent en rien à la Guinée. La présence notée dans un carnet. Les résultats affichés sur une feuille punaisée au mur. Les parents apprennent que leur enfant est en échec quand l’année est déjà terminée.

Le vide

Chaque développeur guinéen qui essaie de régler un bout du problème — un outil de suivi des notes, une appli de présence, un portail parents — repart de zéro. Il n’y a pas de backend commun. Pas d’API partagée pour les inscriptions, la notation ou la gestion des cours sur laquelle les équipes locales pourraient construire. Alors les efforts se dupliquent, les projets stagnent, et rien n’atteint l’échelle.

Ce qu’une API LMS sans interface résout

Un LMS headless, c’est uniquement la couche backend. Il gère les données et la logique — inscriptions, notes, présence, diffusion de contenu, notifications — et expose tout ça via des APIs propres. N’importe quel développeur peut brancher le frontend qui a du sens : une appli web, une appli mobile, une interface SMS, un menu USSD pour les téléphones basiques.

Les écoles obtiennent un système qui s’adapte à leur fonctionnement au lieu d’en imposer un nouveau. Les développeurs obtiennent une fondation au lieu d’une page blanche. Les parents obtiennent de la visibilité. Les étudiants obtiennent des relevés auxquels ils peuvent réellement accéder.

Ce que ça couvrirait

  • Authentification et rôles — étudiants, enseignants, parents, administrateurs, chacun voyant ce dont il a besoin
  • Cours et contenus — modules, leçons, quiz, devoirs
  • Inscriptions et présence — qui est inscrit, qui s’est présenté, alertes quand ce n’est pas le cas
  • Notes et relevés — calculs automatiques, documents téléchargeables, certificats
  • Notifications — SMS via les passerelles Orange/MTN, email, in-app
  • Paiements — frais de scolarité via mobile money

Les défis propres à la Guinée

La connectivité. En dehors de Conakry, internet est instable. L’API doit supporter des clients offline-first qui se synchronisent quand une connexion apparaît. Les réponses doivent être légères. Chaque octet compte sur un partage de connexion.

Le mobile d’abord. La plupart des utilisateurs accéderont au système depuis un téléphone, pas un laptop. L’API doit bien servir des clients légers. Le SMS et l’USSD comme canaux ne sont pas des bonus — c’est le cœur.

Les langues locales. Le français est la langue officielle, mais le soussou, le peul et le malinké sont ce que les gens parlent à la maison. Les couches contenu et notification doivent être multilingues dès le premier jour.

La confiance. Les écoles et les parents doivent faire confiance au système avec les données des élèves. L’accès par rôles, les journaux d’audit et la résidence des données comptent ici.

Projets connexes

Statut actuel

C’est au stade du concept. Je cartographie les besoins à partir de ce que j’entends des étudiants, des responsables d’établissements et des développeurs à Conakry. Si vous travaillez dans l’edtech ou l’éducation en Afrique de l’Ouest, je veux savoir ce que vous construisez : laminekalinko2@gmail.com