Edge computing

Edge computing : Exécution de traitements sur des serveurs proches de l’utilisateur, qui réduit la latence perçue sur les appels courts et répétés.

Famille « Technique ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Pourquoi Edge computing compte sur un projet mobile

Edge computing appartient à la plomberie de l’application, la partie que personne ne montre en démonstration et qui explique pourtant une bonne moitié des retards.

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

La traduction en exigences

Écrire « Edge computing » dans un cahier des charges ne suffit pas. Il faut préciser le comportement attendu quand ça tombe en panne, parce que c’est ce cas-là que les utilisateurs vivront.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Comment le vérifier à la recette

Le contrôle de « Edge computing » demande d’aller voir derrière l’écran : journaux, mesures, comportement en panne.

• Couper le réseau en pleine utilisation et regarder ce que l’application affiche.
• Tester sur une connexion lente, pas seulement sur le Wi-Fi du bureau.
• Lire les journaux d’erreurs de la première semaine de production.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Erreurs fréquentes

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Recetter uniquement sur le Wi-Fi du bureau, puis découvrir le comportement réel en mobilité.
• Oublier le mode dégradé : ce que l’application affiche quand le serveur ne répond pas.
• Laisser les intégrations tierces sans limite d’appel ni conduite à tenir en cas de panne du fournisseur.
• Sortir la supervision et les alertes du périmètre pour tenir le budget initial.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Webhook
• Notification push
• Lien profond
• Feature flag

Questions fréquentes

Qu’est-ce que « Edge computing » ?

Exécution de traitements sur des serveurs proches de l’utilisateur, qui réduit la latence perçue sur les appels courts et répétés. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Qui vérifie que c’est bien fait ?

Le client, à la recette, avec un critère écrit à l’avance. À défaut, personne : ces sujets ne se voient pas à l’écran, et un utilisateur ne signale que leurs conséquences.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.