Point de terminaison non documenté

Point de terminaison non documenté : Interface utilisée par l’application mais absente de la documentation, qui reste accessible et doit donc être protégée.

Classé dans la famille « Sécurité », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

À quoi sert Point de terminaison non documenté

Sur un projet d’application, Point de terminaison non documenté se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

Comment l’écrire dans un cahier des charges

Écrire « Point de terminaison non documenté » dans un cahier des charges engage un travail réel, pas une case à cocher : configuration, code, procédure, et preuve à produire.

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

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Vérifier plutôt que croire

Le contrôle de « Point de terminaison non documenté » ne s’arrête pas à l’application : les interfaces qu’elle appelle font partie du périmètre.

• Contrôler qu’aucun secret ne traîne dans le code livré.
• Passer en revue la liste des personnes ayant accès à la production.
• S’assurer que les journaux ne contiennent aucune donnée personnelle.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

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.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

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

• Effacement à distance
• Déni de service

Questions fréquentes

Point de terminaison non documenté : de quoi parle-t-on exactement ?

Interface utilisée par l’application mais absente de la documentation, qui reste accessible et doit donc être protégée. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

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