interface

interface : Déclaration Java ou Kotlin d’un comportement attendu, sans implémentation ni héritage imposé, ce qui autorise plusieurs réalisations d’un même contrat.

Famille « Développement ». 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.

À quoi sert interface

interface fait partie des notions invisibles à l’usage et bien réelles dans la facture. Ce point décide de la facilité avec laquelle une équipe reprendra le code dans deux ans, avec d’autres développeurs.

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.

De la définition à la ligne de cahier des charges

Un cahier des charges qui mentionne « interface » doit dire pourquoi. Sans justification écrite, la mention devient une préférence technique que personne ne saura arbitrer six mois plus tard.

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

• Le niveau de tests automatisés attendu, et ce qui déclenche un refus de recette.
• La documentation technique livrée, et à qui elle doit permettre de reprendre le projet.
• L’environnement de recette, distinct de la production, et la liste de ceux qui y accèdent.
• Le format de livraison des sources, des comptes de service et des clés de signature.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

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

interface ne se voit pas à l’usage. C’est pour cette raison qu’il faut le vérifier explicitement, sinon personne ne le fera.

• Vérifier que le projet se compile chez quelqu’un d’autre, à partir du dépôt seul.
• Lire le rapport de tests automatisés fourni avec la livraison.
• Comparer le périmètre livré à la liste des critères d’acceptation, ligne par ligne.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Ce qui tourne mal le plus souvent

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Imposer une technologie dans le cahier des charges sans écrire le besoin qu’elle sert.
• Accepter un devis où le développement iOS et le développement Android tiennent dans une seule ligne.
• Repousser les tests automatisés à la fin du projet, c’est-à-dire ne jamais les écrire.
• Changer de socle technique en cours de route sans rechiffrer le reste du planning.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

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

• Flutter
• React Native
• Swift
• Kotlin
• ObservableObject

Questions fréquentes

Qu’est-ce que « interface » ?

Déclaration Java ou Kotlin d’un comportement attendu, sans implémentation ni héritage imposé, ce qui autorise plusieurs réalisations d’un même contrat. 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.

Faut-il l’imposer dans le cahier des charges ?

Écrivez le besoin et la contrainte, pas la solution. Si un choix technique précis est indispensable, à cause de l’existant ou des compétences internes, justifiez-le en une phrase : un prestataire pourra le respecter, ou proposer mieux avec un argument.

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.