référence faible

référence faible : Référence qui ne retient pas l’objet pointé, outil principal pour casser un cycle de rétention entre une vue et son modèle.

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 référence faible

référence faible 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.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

La traduction en exigences

Le cahier des charges gagne à formuler « référence faible » en résultat attendu plutôt qu’en solution : ce que l’application doit savoir faire, à quel moment, et comment on le vérifiera à la recette.

À é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.

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.

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.

Ce que ça change au moment de la recette

À la recette, référence faible se contrôle avec les mêmes gestes à chaque version. Ce sont ces gestes qu’il faut écrire une fois pour toutes.

• 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.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Les pièges à éviter

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

• Laisser la remise du code hors du contrat, puis découvrir que le dépôt n’est pas transmis.
• Confondre bibliothèque gratuite et bibliothèque sans coût : certaines licences se paient à l’usage.
• Croire qu’un développeur reprend le travail d’un autre sans documentation ni période de recouvrement.
• Traiter la dette technique comme une affaire interne à l’agence : elle sera facturée au suivant.
• 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 :

• LLDB
• Flutter
• React Native
• Swift
• Kotlin

Questions fréquentes

Qu’est-ce que « référence faible » ?

Référence qui ne retient pas l’objet pointé, outil principal pour casser un cycle de rétention entre une vue et son modèle. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Est-ce que ça change le prix de l’application ?

Rarement seul, souvent en cumul. Ces décisions pèsent surtout sur le coût des évolutions : ce qui est facile à modifier coûte moins cher sur trois ans qu’une économie faite au moment de la construction.

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.