Checklist de mise en production pour une app créée par IA

Avant tout le reste : ce qui est exposé

Ce sont les points où le mal est déjà fait au moment où vous vous en apercevez, alors ils viennent en premier, quelle que soit la façon dont votre app est construite.

• Cherchez des clés dans l'historique de votre dépôt, pas seulement dans les fichiers actuels. Un secret commité une fois puis supprimé est toujours dans l'historique et fonctionne toujours.
• Ouvrez les outils de développement du navigateur sur votre propre site, regardez l'onglet réseau, et vérifiez ce que contient le bundle envoyé au navigateur. Tout ce que le navigateur peut lire, un inconnu peut le lire.
• Prenez une URL qui affiche vos propres données, déconnectez-vous, et ouvrez-la à nouveau. Si elle marche encore, les données de tous les autres utilisateurs marchent de la même façon.
• Changez l'identifiant dans cette URL pour celui de quelqu'un d'autre. C'est le trou le plus fréquent dans le code généré, parce qu'on a demandé au générateur d'afficher les données, pas de vérifier qui les demande.
• Regardez ce que disent vos pages d'erreur. Une trace d'exécution en production indique à un inconnu la forme de votre base de données.

Ensuite : ce qui se passe quand ça s'arrête

• Tuez le processus et regardez. Est-ce qu'il revient tout seul, ou est-ce qu'il reste mort jusqu'à ce que quelqu'un s'en aperçoive ?
• Est-ce que vous l'apprendriez ? Pas « est-ce qu'il y a un tableau de bord » — est-ce qu'un message vous parviendrait, sur un appareil que vous regardez, avant qu'un client ne vous écrive ?
• Déployez quelque chose de cassé exprès, sur une copie. Combien de temps faut-il pour récupérer la version précédente, et connaissez-vous la commande sans aller la chercher ?
• Écrivez ce qui se passe si le seul fournisseur dont vous dépendez tombe en panne. Vous pouvez décider de l'accepter ; c'est le fait de décider qui compte.

Ensuite : si vos données survivent

C'est le point sur lequel les gens sont les plus sûrs d'eux et se trompent le plus souvent, parce que la sauvegarde existe en général et n'a jamais servi.

• Restaurez une sauvegarde dans un environnement jetable. Faites-le vraiment. Une sauvegarde non testée n'est pas une sauvegarde — c'est un fichier sur lequel on fonde un espoir.
• Vérifiez jusqu'où remontent les sauvegardes et à quelle fréquence elles tournent. Chaque nuit et sept jours d'historique est un choix ; ne pas savoir n'en est pas un.
• Vérifiez que la sauvegarde n'est pas stockée uniquement dans le compte qui héberge la chose sauvegardée.
• Si votre migration de base de données a un chemin de rollback, lisez-le. Un rollback qui supprime une colonne dont un déploiement en ligne a encore besoin, c'est une perte de données sous un nom sympathique.

Ensuite : ce qui expire tout seul

• Le certificat TLS. S'il n'est pas renouvelé automatiquement, mettez la date d'expiration dans votre agenda maintenant — sinon il expirera un week-end.
• Le renouvellement du domaine, et si la carte enregistrée est toujours valide.
• Les clés d'API et les tokens OAuth qui ont une date d'expiration, en particulier chez les prestataires de paiement et d'e-mail.
• Les offres gratuites sur lesquelles vous avez construit. Elles changent, et le changement arrive sous la forme d'un e-mail que vous ne lirez pas.

Ensuite : les points ennuyeux, ceux du bon fonctionnement

• Chaque appel sortant a un timeout. Une requête sans timeout n'échoue pas — elle reste suspendue, et elle emporte le processus avec elle.
• Les tentatives de reprise sont bornées, et n'enveloppent que des opérations qu'on peut répéter sans risque. Une reprise sans limite sur « envoyer de l'argent » n'est pas une fonction de résilience.
• Une limitation de débit sur tout ce qu'un inconnu peut appeler, en particulier le formulaire de votre page marketing.
• Testez ce qui se passe avec une entrée très grande et une entrée très étrange — un emoji, une apostrophe, un collage de 10MB.
• Si deux personnes peuvent agir au même moment, testez cela, pas un substitut séquentiel.

Enfin : celui que personne n'écrit

Est-ce que quelqu'un d'autre que vous peut faire tourner ça ? Si votre app ne peut être déployée que depuis votre portable, avec vos clés, en suivant des étapes qui vivent dans votre tête, alors le risque n'est plus technique. Écrivez le runbook — comment la faire tourner, comment la déployer, comment revenir en arrière — et donnez-le à quelqu'un pour qu'il le suive pendant que vous ne dites rien. Ce sur quoi il bloque est l'état réel de votre documentation.

Si vous préférez que quelqu'un d'autre le fasse

C'est le Bilan de production : nous parcourons cette liste sur votre base de code et l'endroit où elle tourne, et nous écrivons ce qui cassera en premier, ce que coûte chaque correction, et dans quel ordre les faire. $450, cinq jours ouvrés, et le rapport est à vous dans tous les cas.

Les questions qu'on nous pose en premier

Le reste de ce que nous faisons

• Bilan de production — Ça marche. Des gens s'en servent. Et personne n'a jamais vérifié ce qui se passe quand ça ne marche plus — qua…
• Le rendre exploitable — Pour quelque chose qui a été construit vite et dont des gens dépendent désormais. Un seul montant fixe, conven…
• Le maintenir en ligne — La partie que personne ne veut prendre en charge. Votre app est en ligne et il faut bien que quelqu'un s'aperç…
• Construire par étapes — À partir d'une idée, ou d'un projet qui s'est enlisé. Chiffré une étape à l'avance et payé par étape, et tout…
• Nos propres produits — ce que nous construisons pour nous-mêmes, et que nous exploitons.