Modifier

Modifier : Chaîne d’instructions Compose qui règle taille, marges, fond et interactions d’un composable, dont l’ordre modifie le résultat visuel.

Ce terme appartient à la famille « Développement ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Où intervient Modifier dans un projet

Modifier 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 mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

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

Un cahier des charges qui mentionne « Modifier » 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 :

• Les versions minimales d’iOS et d’Android supportées, qui décident des API disponibles.
• Le sort du code : dépôt remis, licences des bibliothèques, cession des droits à la livraison.
• Les bibliothèques tierces autorisées, et qui paie leurs licences dans la durée.
• La procédure de mise à jour de l’application une fois qu’elle est publiée.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

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.

Les contrôles à prévoir

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

• Lire le rapport de tests automatisés fourni avec la livraison.
• Vérifier que les clés de signature et les comptes de service sont remis, pas seulement promis.
• Comparer le périmètre livré à la liste des critères d’acceptation, ligne par ligne.

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

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

• Flutter
• React Native
• Swift
• Kotlin
• ObservableObject

Questions fréquentes

Modifier : de quoi parle-t-on exactement ?

Chaîne d’instructions Compose qui règle taille, marges, fond et interactions d’un composable, dont l’ordre modifie le résultat visuel. 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.

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.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

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