Une entreprise de rénovation et de maintenance de logements sociaux appelait chaque locataire pour fixer ses interventions. Nous avons ajouté à son ERP un module qui laisse les locataires et les gardiens choisir eux-mêmes leur créneau, depuis leur téléphone.
L’entreprise intervient pour le compte de bailleurs sociaux dans des immeubles occupés : plomberie, maintenance, petits travaux. Chaque intervention demande l’accès à un ou plusieurs logements, et parfois aux parties communes.
Le planificateur appelait chaque locataire, puis le gardien, cherchait un créneau commun, rappelait en cas d’absence et reportait le résultat à la main dans le planning. Avec plusieurs difficultés :
L’objectif : laisser le destinataire choisir lui-même son créneau, au moment qui lui convient, sans installer d’application ni créer de compte, et mettre à jour le planning automatiquement.
Le planificateur propose un ou plusieurs créneaux sur la fiche d’intervention. Chaque personne concernée reçoit un SMS avec un lien personnel, choisit un créneau ou refuse. Quand toutes les réponses sont arrivées, le rendez-vous se fixe dans le planning.
Les destinataires sont déduits des localisations de l’intervention : le locataire pour un appartement, le gardien référent pour une partie commune. Une intervention sur trois logements crée trois demandes, chacune avec son lien.
Le nom du bailleur, l’objet de l’intervention, le lien personnel et un numéro pour ceux qui préfèrent appeler. L’envoi peut partir tout de suite ou être préparé pour plus tard.
Le lien ouvre une page aux couleurs de l’entreprise et du bailleur, qui rappelle l’adresse et le logement puis liste les créneaux. Une fois le rendez-vous tranché, elle devient une simple consultation.
Sans réponse au bout de quatre heures, le SMS est renvoyé une fois, pas plus, pour ne pas harceler le destinataire ni consommer de crédits inutilement.
Envoi, relance, acceptation ou refus de chaque destinataire, rendez-vous fixé : en cas de litige, on sait qui a été sollicité, quand, et ce qui a été répondu.
Les administrateurs voient les crédits SMS restants chez le fournisseur et anticipent le réapprovisionnement.
L’intervention n’a lieu qu’une fois : le technicien doit accéder à tous les logements pendant le même passage. À chaque réponse, le statut du rendez-vous est recalculé.
Rendez-vous validé, date et heures reportées dans le planning.
Rendez-vous refusé, le planificateur propose de nouveaux créneaux.
Rendez-vous refusé.
Rendez-vous en attente.
Un SMS non reçu, c’est un rendez-vous perdu. Plutôt qu’une simple alerte, le module bascule automatiquement sur un second fournisseur quand le premier est indisponible ou à court de crédits.
API REST en JSON, authentification par jeton, plusieurs destinataires en un seul appel.
API HTTP, un appel par destinataire, encodage du texte converti automatiquement. Il prend le relais dès que le fournisseur principal échoue.
Les deux API n’ont rien en commun : format, authentification, nombre de destinataires par appel, encodage. Le reste de l’application n’en sait rien : il envoie un texte et une liste de numéros à un service unique, qui choisit le fournisseur. Changer de fournisseur, ou en ajouter un, ne touche ni les écrans ni les règles métier.
Les identifiants des fournisseurs sont lus dans la configuration du serveur, jamais dans le code. Un interrupteur coupe tout envoi réel en développement et en recette : aucun SMS ne part, aucun crédit n’est consommé.
Demander un compte à des particuliers ferait chuter le taux de réponse. La page est donc accessible sans connexion, avec plusieurs protections :
Au-delà de 160 caractères, un SMS est découpé et facturé plusieurs fois. Le message est réduit au nécessaire et le nom du bailleur raccourci pour garder une longueur prévisible. L’identifiant expéditeur est limité à 11 caractères.
Envoi réel coupé hors production, une seule relance par demande, envoi immédiat optionnel et solde de crédits visible : le module limite la dépense sans freiner l’usage.
Le module s’insère dans un ERP déjà en production et réutilise ses mécanismes : droits par module, historique des interventions, tables de référence. Aucune architecture parallèle n’a été créée.
Plus d’appels en série. Il propose des créneaux, suit l’avancement des réponses et récupère un rendez-vous fixé automatiquement.
Il répond quand il veut, en quelques secondes, depuis son téléphone, sans compte ni application.
Une preuve écrite de chaque sollicitation et de chaque réponse, et une continuité de service grâce au second fournisseur.
Ce que nous en retenons : isoler chaque service externe derrière une interface simple, prévoir l’échec dès la conception, traiter une page publique comme une surface d’attaque, et laisser le coût de chaque SMS guider l’architecture.
Non. Il reçoit un SMS avec un lien personnel, ouvre une page web et choisit son créneau. Un numéro de téléphone reste indiqué pour ceux qui préfèrent appeler.
L’envoi bascule automatiquement sur un second fournisseur. Le reste de l’application ne voit pas la différence, et le destinataire reçoit son SMS.
Chaque demande a son propre lien, impossible à deviner. La page ne propose que les créneaux du rendez-vous, n’affiche que le minimum d’informations et n’accepte plus de réponse une fois le rendez-vous tranché.
S’il peut être étendu, oui : le module réutilise les interventions, les logements et les droits existants. Sinon, nous étudions un module relié à vos données. Voir envoyer des SMS depuis votre logiciel métier.
Décrivez-nous votre logiciel et la façon dont vos interventions sont planifiées. Nous intégrons le fournisseur SMS de votre choix, y compris Novixo, l’API que nous éditons. Voir aussi notre page intégration API SMS nos solutions pour le BTP, et une autre réalisation dans le même ERP : la plateforme de support intégrée par API.