rédactionFonctionne bien avec ClaudeFonctionne bien avec ChatGPTFonctionne bien avec Gemini

Transformer une décision en ADR ou dans la documentation que vous aviez sautée

La documentation est la tâche que les développeurs souhaitent le plus déléguer — rédiger des commentaires de code ou de la documentation, et résumer les changements de code récents, figurent parmi les cinq tâches IA les plus courantes, et documenter le code est le domaine où 31 % s'appuient déjà principalement sur l'IA. Les Architecture Decision Records en particulier : le raisonnement est encore frais dans votre tête, mais le rédiger est la corvée qu'on saute, laissant le prochain ingénieur reconstituer par déduction pourquoi le système est ce qu'il est.

Vous êtes un ingénieur staff qui rédige une documentation technique claire et précise. Transformez mes notes en un(e) {{doc_type}} clair(e) pour les autres ingénieurs.

Public et où ce document vivra : {{audience}}
Mes notes brutes — la décision, le contexte et les compromis que j'ai pesés :
{{notes}}

Pour un ADR, utilisez cette structure : Titre ; Statut ; Contexte (le problème et les contraintes) ; Décision (ce que nous avons choisi, énoncé clairement) ; Conséquences (compromis, ce qui devient plus difficile, ce à quoi nous nous engageons désormais) ; Alternatives envisagées (chacune avec la raison de son rejet).

Règles :
- N'utilisez que les faits, décisions et compromis présents dans mes notes. N'inventez pas de benchmarks, d'exigences, de dates ou d'alternatives que je n'ai pas mentionnés. Là où un détail nécessaire manque clairement, insérez « [TODO : à confirmer] » plutôt que de le combler vous-même.
- Restez concis et facile à parcourir — sections courtes, voix active, pas de ton marketing.
- Préservez mes décisions techniques exactement telles quelles ; vous les rédigez, vous ne les reprenez pas.
- Terminez par une courte liste de questions ouvertes qu'un relecteur devrait résoudre.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

Type de documentPublic et emplacement du documentVos notes brutes (à coller)

Ce que vous obtenez (extrait)

Titre : utiliser la sécurité au niveau des lignes de Postgres pour l'isolation des locataires Statut : proposé Contexte : nous hébergeons plusieurs locataires dans une seule base de données. Le filtrage au niveau applicatif a causé deux fuites de données inter-locataires ce trimestre. Décision : appliquer l'isolation via des politiques de sécurité au niveau des lignes (row-level security) de Postgres, indexées sur tenant_id, définies par connexion. Conséquences : garantie forte au niveau de la base de données ; chaque connexion doit définir l'identifiant du locataire, sinon les requêtes ne retournent rien. Les migrations deviennent plus complexes. [TODO : à confirmer] l'impact sur les performances sous notre charge. Alternatives envisagées : une base de données séparée par locataire — rejetée pour la charge opérationnelle ; poursuivre le filtrage au niveau applicatif — rejeté après des fuites répétées. Questions ouvertes : compatibilité avec le connection pooler ; ordre de déploiement entre les services.

Le flux de travail complet

Notez d'abord en vrac la décision, le contexte et les compromis
Générez l'ADR ou le document, puis relisez-le en le comparant à ce que vous avez réellement décidé
Remplacez chaque « [TODO : à confirmer] » par une valeur réelle et supprimez tout ce que le modèle a déduit de lui-même
Committez le document avec le code pour qu'il reste repérable et versionné

Attention à

Le modèle comble les lacunes en inventant une justification, des exigences ou des alternatives que vous n'avez jamais envisagées. La documentation fait référence pour les autres ingénieurs qui agissent en conséquence — vérifiez que chaque affirmation reflète la décision réelle.

Ne collez pas d'architecture confidentielle, de détails de sécurité ou de code propriétaire dans un outil grand public. Les documents de conception internes sont des secrets d'affaires ; utilisez un outil approuvé avec entraînement désactivé.

L'IA peut reformuler une décision mais ne peut pas en être responsable. Le jugement d'ingénierie contenu dans un ADR vous appartient, et un relecteur doit tout de même le valider.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les développeurs en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les développeurs

analyse

Transformer une décision en ADR ou dans la documentation que vous aviez sautée

Le flux de travail complet

Attention à

D’où ça vient

Plus de cas d’usage de l’IA pour les développeurs

Faire expliquer un code inconnu avant de le modifier

Une première relecture de votre diff avant qu'un humain ne le voie

Générer des tests unitaires que vous validez ensuite par rapport à la spécification

Déboguer avec la méthode du canard en plastique un problème qui vous résiste

Rédiger des messages de commit et des descriptions de PR à partir de votre diff