anchor.diff:  - les transitions sont dessinés comme des flêches droites
   - le positionnement des étiquettes et choisi naïvement
   
  -=== Produit attendu
  +==== Produit attendu
   
   - Une interface adaptative
   - Un canvas de taille variable
  
positive.code: l'utilisateur (pas/peu de caractères spéciaux, inférence des états, etc.)
  - Les erreurs dans la description sont repérées et proprement signalées
  
  === Améliorations envisageables
  
  Les améliorations suivantes sont présentées de façon désordonnées, bien que
  certaines semblent nécessaires tandis que d'autres sont probablement de l'ordre
  du fantasme. L'idée est de lister toutes les routes que peut prendre le
  développement de l'application déterminer ainsi les plus pertinents.
  
negative.code: du document. C'est, au vu de la définition du produit attendu, le cas
  d'utilisation le plus évident.
  
  === Les alternatives
  
  Un moteur de rendu d'automate à partir d'un DSL existe déjà. Il s'agit
  de GraphViz qui, à partir d'une figure décrite dans le langage _dot_, peut
  produire un dessin sous format SVG. GraphViz peut représenter bien d'autres
  objets, et peut le faire dans bien d'autres formats.
  
  Toutefois, GraphViz et _dot_ requièrent pour une application Web un rendu
  côté serveur
  (une http://ushiroad.com/jsviz/[implémentation en Javascript] existe cependant).
  De plus, _dot_ s'attache à la sémantique des graphes et non des automates.
  
  Afin de justifier la pertinence de notre application, il nous faut déterminer
  les cas d'utilisation pour lesquels GraphViz et _dot_ pêchent et proposer
  ainsi une meilleure alternative.
  
  == Architecture
  
  === Trois étapes
  